Selecting Best Compatible Driver (Windows XP)

We have a driver package that is installed by when our software is
installed. It is installed in to the Driver Store using the
DriverPackagePreinstall function. The drivers are for a USB communication
adapter for an industrial network. Because it is a custom driver class it
canâ??t be tested by Microsoftâ?? hardware lab. All the files are digitally
signed and the catalog file is signed as well. In most cases the driver
install fine when the USB adapter is plugged into the system.

We recently found a problem with a system that was taking 10 minutes to
search for the driver. We looked at the setupapi.log file and found that the
system was scanning a DVD we happened to have in the drive. The DVD happened
to have a lot of files as well as 270 INF files on it. I did some research
and found that only the path specified in the
HKLM\Software\Microsoft\Windows\CurrentVersion DevicePath is supposed to be
searched. The only path specified was %SystemRoot%\INF. Our INF file was in
the Windows\INF directory and that was the INF file that was used after the
search.

My question is why does the DVD get searched when it isnâ??t specified in the
search path? Is there a way to stop it (this doesnâ??t happen on Vista
systems). Also, the setupapi.log file gives many warnings indicating that the
driver isnâ??t signed when all files and the catalog file are correctly signed.
Is this a bug that will be fixed or is the fact that the file is signed not
detected for some reason?

See part of the setupapi.log file below.

Thanks,
--
Brian


[SetupAPI Log]
OS Version = 5.1.2600 Service Pack 2
Platform ID = 2 (NT)
Service Pack = 2.0
Suite = 0x0100
Product Type = 1
Architecture = x86
[2008/05/08 12:22:13 620.3 Driver Install]
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#-198 Command line processed: C:\WINDOWS\system32\services.exe
#I022 Found "USB\Vid_5854&Pid_9005&Rev_0001" in C:\WINDOWS\inf\oem4.inf;
Device: "Schneider Electric USB Controller"; Driver: "Schneider Electric USB
Controller"; Provider: "Cyberlogic Technologies, Inc."; Mfg: "Schneider
Automation, Inc."; Section name: "TSXCUSBMBP_Install".
#I087 Driver node not trusted, rank changed from 0x00000000 to 0x00008000.
#I023 Actual install section: [TSXCUSBMBP_Install.NT]. Rank: 0x00008000.
Effective driver date: 03/28/2008.
#I393 Modified INF cache "C:\WINDOWS\inf\INFCACHE.1".
#-147 Loading class installer module for "USB Device".
#E358 An unsigned or incorrectly signed file "C:\WINDOWS\system32\MbxCi.dll"
for driver "USB Device" blocked (server install). Error 0x800b0110: The
certificate is not valid for the requested usage.
Windows could not load the installer for MODICON_MBX. Contact your hardware
vendor for assistance. Error 0x800b0110: The certificate is not valid for the
requested usage.
[2008/05/08 12:22:15 1596.2]
#-199 Executing "C:\WINDOWS\system32\rundll32.exe" with command line:
rundll32.exe newdev.dll,ClientSideInstall
\\.\pipe\PNP_Device_Install_Pipe_0.{65BD9C5E-9D98-4A4E-A54E-3BD028DDE1D6}
#I060 Set selected driver.
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#I022 Found "USB\Vid_5854&Pid_9005&Rev_0001" in C:\WINDOWS\inf\oem4.inf;
Device: "Schneider Electric USB Controller"; Driver: "Schneider Electric USB
Controller"; Provider: "Cyberlogic Technologies, Inc."; Mfg: "Schneider
Automation, Inc."; Section name: "TSXCUSBMBP_Install".
#I087 Driver node not trusted, rank changed from 0x00000000 to 0x00008000.
#I023 Actual install section: [TSXCUSBMBP_Install.NT]. Rank: 0x00008000.
Effective driver date: 03/28/2008.
#-147 Loading class installer module for "USB Device".
#E360 An unsigned or incorrectly signed file "C:\WINDOWS\system32\MbxCi.dll"
for driver "USB Device" will be installed (Policy=Ignore). Error 0x800b0110:
The certificate is not valid for the requested usage.
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#I063 Selected driver installs from section [TSXCUSBMBP_Install] in
"c:\windows\inf\oem4.inf".
#I320 Class GUID of device remains: {01F5ED20-0BCB-11D4-A02A-00E0290C8B76}.
#I060 Set selected driver.
#I058 Selected best compatible driver.
#I060 Set selected driver.
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#I022 Found "USB\Vid_5854&Pid_9005&Rev_0001" in C:\WINDOWS\inf\oem4.inf;
Device: "Schneider Electric USB Controller"; Driver: "Schneider Electric USB
Controller"; Provider: "Cyberlogic Technologies, Inc."; Mfg: "Schneider
Automation, Inc."; Section name: "TSXCUSBMBP_Install".
#I087 Driver node not trusted, rank changed from 0x00000000 to 0x00008000.
#I023 Actual install section: [TSXCUSBMBP_Install.NT]. Rank: 0x00008000.
Effective driver date: 03/28/2008.
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff
#-019 Searching for hardware ID(s):
usb\vid_5854&pid_9005&rev_0001,usb\vid_5854&pid_9005
#-018 Searching for compatible ID(s):
usb\class_ff&subclass_ff&prot_ff,usb\class_ff&subclass_ff,usb\class_ff

chris
Thu May 08 12:58:53 CDT 2008

On May 8, 12:10 pm, Brianhub <Brian...@discussions.microsoft.com>
wrote:

> The drivers are for a USB communication adapter for an industrial
> network. Because it is a custom driver class it can=92t be tested
> by Microsoft=92 hardware lab.

Not true at all, there is an "Unclassified" suite in DTM that will
allow you to get a WHQL signature for a custom device class.

> systems). Also, the setupapi.log file gives many warnings indicating that =
the
> driver isn=92t signed when all files and the catalog file are correctly si=
gned.
> Is this a bug that will be fixed or is the fact that the file is signed no=
t
> detected for some reason?

XP x86 doesn't care about Authenticode signatures at all. For built-
in device classes it will behave as if your driver is totally
unsigned. For custom device classes, I think you might skip a warning
box or two, but you will still see such errors in setupapi.log.

Brianhub
Thu May 08 14:37:04 CDT 2008

Chris,

Thanks for the quick response. I didn't realize the custom driver could get
a WHQL signature. We may look into that.

Is there any way to prevent the searching of removeable media like the DVD
for INF files when the system is trying to determine the best driver?
--
Brian


"chris.aseltine@gmail.com" wrote:

> On May 8, 12:10 pm, Brianhub <Brian...@discussions.microsoft.com>
> wrote:
>
> > The drivers are for a USB communication adapter for an industrial
> > network. Because it is a custom driver class it canâ??t be tested
> > by Microsoftâ?? hardware lab.
>
> Not true at all, there is an "Unclassified" suite in DTM that will
> allow you to get a WHQL signature for a custom device class.
>
> > systems). Also, the setupapi.log file gives many warnings indicating that the
> > driver isnâ??t signed when all files and the catalog file are correctly signed.
> > Is this a bug that will be fixed or is the fact that the file is signed not
> > detected for some reason?
>
> XP x86 doesn't care about Authenticode signatures at all. For built-
> in device classes it will behave as if your driver is totally
> unsigned. For custom device classes, I think you might skip a warning
> box or two, but you will still see such errors in setupapi.log.
>

mirage2k2
Thu May 08 20:59:00 CDT 2008

my experience with driver install is that windows likes to look everywhere
else first before looking at the infs you provide (I'm assuming that you have
inf for your driver and that it is part of your install package).

Windows usually first looks in infcache file, in windows\inf, and sometimes
entries in this file can lead to your driver not being installed correctly.
When I come across a certain system that has trouble installing my driver,
the first thing I do is delete the infcache (usually named INFCACHE.1). This
normally fixes my problem! On one system I tried everything and my driver
would not install, finally I ran a registry fixup/cleanup tool and this fixed
it - this may also be the answer for the system you mention that always looks
on DVD.

Another common problem you may encounter is when a system contains older
versions of your inf file. In this case windows usually installs your driver
using the existing older versions instead of the current one provided in your
install package.

mirage

"Brianhub" wrote:

> Chris,
>
> Thanks for the quick response. I didn't realize the custom driver could get
> a WHQL signature. We may look into that.
>
> Is there any way to prevent the searching of removeable media like the DVD
> for INF files when the system is trying to determine the best driver?
> --
> Brian
>
>
> "chris.aseltine@gmail.com" wrote:
>
> > On May 8, 12:10 pm, Brianhub <Brian...@discussions.microsoft.com>
> > wrote:
> >
> > > The drivers are for a USB communication adapter for an industrial
> > > network. Because it is a custom driver class it canâ??t be tested
> > > by Microsoftâ?? hardware lab.
> >
> > Not true at all, there is an "Unclassified" suite in DTM that will
> > allow you to get a WHQL signature for a custom device class.
> >
> > > systems). Also, the setupapi.log file gives many warnings indicating that the
> > > driver isnâ??t signed when all files and the catalog file are correctly signed.
> > > Is this a bug that will be fixed or is the fact that the file is signed not
> > > detected for some reason?
> >
> > XP x86 doesn't care about Authenticode signatures at all. For built-
> > in device classes it will behave as if your driver is totally
> > unsigned. For custom device classes, I think you might skip a warning
> > box or two, but you will still see such errors in setupapi.log.
> >