the error I get when I componentize a third party driver

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I get the error "INF Importer could not find any recognizable installation to convert in the file"when I componentize a third party driver.I can not find the resolvent in the article "I've Componentized a Driver and I Get Errors".Dos it mean that the INF file is unavailable in componentization.But it can be installed successfully in XPE after adding the "Add Hardware"component.Of course it work in windows xpp.
 
fan,

Is it a PnP driver?
Then you don't need to import the INF. Just copy all the necesary files
(INF, DLLs, etc.) to appropriate directies at run time (\windows\inf,
\windows\system32, etc.). FBA PnP will do the rest.

This theread may help:
http://groups.google.com/groups?hl=...=1&selm=#[email protected]

Another way would be in changing the INF manually. Read about INF format in
Windows DDK documentaiton.

Regards,
KM
I get the error "INF Importer could not find any recognizable
Click to expand...
installation to convert in the file"when I componentize a third party
driver.I can not find the resolvent in the article "I've Componentized a
Driver and I Get Errors".Dos it mean that the INF file is unavailable in
componentization.But it can be installed successfully in XPE after adding
the "Add Hardware"component.Of course it work in windows xpp.
 
Hi KM:
Thank you for your answer!
It is a pci device and may be not a pnp one.But it works when I copy the
files to the run time.Thanks a lot.
Best wishes!
Fan
 
fan,

I am glad it helped you.
Seems like Slobodan and me are trying to convince people to use INF Importer from XPe Tools as least as possible :-)
 
Konstantin,
Seems like Slobodan and me are trying to convince people to use INF Importer from XPe Tools as least as possible :-)
Click to expand...

It appears so, although importer tool is essential in process of easy creation of boot critical driver components. Although so far I
have not found a hardware that XPe can't boot with Standard drivers and then install inf files.

Regards,
Slobodan
 
Slobodan,
It appears so, although importer tool is essential in process of easy creation of boot critical driver components.
Click to expand...

True. Although you can always create a PnP Service Data resource to set the driver start type. But I guess you have to know that the
driver is critical to start at boot or kernel phase, for instance.
Also I noticed one thing. Some boot critical driver inf's (3rd parties) do not have StartType=0 set for whatever reasons. You have
to go and set the flag in the importer result PnP Service Resource manually. Otherwise the INF imported component will fail (or not
start) at run time.

Konstantin
 
Hi Konstantin,

Actually StartType=0 only tells ntldr to load specific driver in memory, nothing more.

I was referring to CriticalDeviceDatabase entry or/and Enum registry entry as an alternative.
CriticalDeviceDatabase entry is filled by TD when cmiIsCriticalDevice is set to TRUE. But it requires some additional info that you
will either enter manually or let CD do the job for you.

You can always fill component registry entries manually of course.

Best regards,
Slobodan
 
Hi Slobodan,
Actually StartType=0 only tells ntldr to load specific driver in memory,
Click to expand...
nothing more.

Correct. I always call boot device as critical. Using wrong term, sorry.
I was referring to CriticalDeviceDatabase entry or/and Enum registry entry as an alternative.
CriticalDeviceDatabase entry is filled by TD when cmiIsCriticalDevice is
Click to expand...
set to TRUE. But it requires some additional info that you will either enter
manually or let CD do the job for you.

Hmm.. I always thought CriticalDeviceDatabase is a list of devices (drivers)
for restore operation. Does it get used anywhere else?
Also, the subkeys of the key come from various INFs (just registry
entries).. so, why cmiIsCriticalDevice is there in CD? Does it do anything?
(I can't see an effect and thought it was just a place holder)

Regards,
Konstantin
 
Hi Konstantin,

OS must use some drivers before PnP find and install right inf files, right? This is when CriticalDeviceDatabase is used, also when
you change hardware it is used again until PnP make a better install match.

Best regards,
Slobodan
 
Slobodan,
OS must use some drivers before PnP find and install right inf files,
Click to expand...
right? This is when CriticalDeviceDatabase is used, also when
you change hardware it is used again until PnP make a better install
Click to expand...
match.

This is clear to me in XP Pro world where you "install OS". But in XPe isn't
most of the critical drivers are pre-installed (registry populated through
PnP resource) during TD build? (they may get updated during FBA PnP, though)

Also, I failed to see if TD uses cmiIsCriticalDevice property. Does the
property make any difference in your builds?

Regards,
Konstantin
 
Hi Konstantin,
Also, I failed to see if TD uses cmiIsCriticalDevice property. Does the
property make any difference in your builds?
Click to expand...

Like I said unclearly before YES. This is only difference that counts.

Best regards,
Slobodan
 
Slobodan,

Yes, it does. I was probably doing something worg before and it did not populate the CriticalDeviceDatabase entry for me.
Now I just played with a Gendisk and noticed the difference.

Sorry for my ignorance and annoyance on the topic. It is just not descriptive info about the CriticalDeviceDatabase on MSDN.

It was unclear to me where TD processes the cmiIsCriticalDevice. I couldn't find the processing code. Now I did. For those who are
interested, here is the description:

Each PnPID resource contributes to the critical device database if cmiIsCriticalDevice is set (meaning loaded at boot time). If
this is the
case, the following happens:
1. REG_SZ value HKLM\...\CriticalDeviceDatabase\<PnPID>\ClassGUID created
2. REG_SZ value HKLM\...\CriticalDeviceDatabase\<PnPID>\Service created
3. REG_MULTI_SZ value HKLM\...\CriticalDeviceDatabase\<PnPID>\UpperFilter created
4. REG_MULTI_SZ value HKLM\...\CriticalDeviceDatabase\<PnPID>\LowerFilter created

<PnPID> is edited from the PnPID property, replacing "\" with "#" to make it legal as a registry key. The case of the name is also
changed to match usage, though comparisons are case insensitive.

The build code also handles the case where multiple components express the same PnPID. In this case it uses IsCompatibleID to
tie-break. The non-compatible PnPID wins, since it is considered the "primary" ID. It uses a dictionary to track the current
compatibility flag for each built PnPID.

Thanks again,
Konstantin
 
Konstantin,

Yes that is roughly it. If I remember correctly UpperFilter and LowerFilter values are optionally created (not always) depending on
component settings in TD .
Also I can't tell for sure but PnPID values in resources should affect in some way how CriticalDeviceDatabase is populated.

Best regards,
Slobodan
 
Slobodan,
Yes that is roughly it. If I remember correctly UpperFilter and LowerFilter values are optionally created (not always) depending on
component settings in TD .
Also I can't tell for sure but PnPID values in resources should affect in some way how CriticalDeviceDatabase is populated.
Click to expand...

Unfortunately, I don't see the entire build code but from the binaries I call tell that if "cmiIsCriticalDevice" is set to TRUE the
"cmiPnPDevClassGUID" advanced property is getting read. Then "PnPID", "ServiceName" and "UpperFilter" resource values are getting
read.
I may only guess that if any value from above is empty the corresponding CriticalDeviceDatabase value/key is not created.

Regards,
Konstantin

 
Konstantin,

Some time ago I have been using different approach.
Put only one component in build and modify it by making few different images for each modification.
Then use regedit to load offline registry (which is almost empty) and see differences.

Regards,
Slobodan
 
That is exactly how I now work with the cmiIsCriticalDevice flag :-) and how I proved (for myself) that the flag is really working.

Again, my lack of understanding was because this cmi property processing code is not in TD but rather in the Mantis DB (this is due
to the fact that it is the Resource Type build code).
 
Back
Top