After plug-in of a non-HID USB device, Windows 7 RC did not prompt for
driver installation from another location, but just disabled the device.
Via device manager and “Update” driver it was possible to get the
correct driver installed, and then everything worked fine.
Did anyone else notice this behavior, too?
Thanks,
Hagen
what does the setup log say? what happens on W7 RTM?
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Hagen Patzke [xxxxx@hotmail.com]
Sent: Friday, October 23, 2009 7:47 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Win7 PnP & USB devices: no prompt for driver anymore?
After plug-in of a non-HID USB device, Windows 7 RC did not prompt for
driver installation from another location, but just disabled the device.
Via device manager and “Update” driver it was possible to get the
correct driver installed, and then everything worked fine.
Did anyone else notice this behavior, too?
Thanks,
Hagen
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
On 10/23/2009 4:51 PM, Doron Holan wrote:
what does the setup log say? what happens on W7 RTM?
Doron, I’ll get the logs from my other machine (will take some time).
Also I’ll try to personally check RTM as soon as I can.
A customer reported “driver install fails” on his Windows 7 system,
that’s why I assume the same problem on RTM as on my RC1 test kit.
The problem seems not to be that the install fails per se, but that
Windows 7 seems to not even try: if a driver is not found “inbox”, and
not found online on “Windows Update”, you don’t get an installation
prompt anymore.
(If you are quick and click on the “installation failed” bubble, you get
a hint to start “hwwiz” and install manually. But that interface is
IMHO not more user-friendly than device manager and “Update driver”.)
Here is the last bit of inf\setupapi.app.log from my Win7/RC1 machine:
–setupapi.app.log–
[Boot Session: 2009/10/22 23:24:52.484]
>> [Build Driver List - USB\VID_0xxx&PID_0002\5&12218DA1&0&4]
>> Section start 2009/10/22 23:26:57.645
cmd: G:\Windows\system32\svchost.exe -k netsvcs
cpy: Policy is set to make all digital signatures equal.
<<< Section end 2009/10/22 23:26:57.723
<<< [Exit status: SUCCESS]
>> [DIF_SELECTBESTCOMPATDRV - USB\VID_0xxx&PID_0002\5&12218DA1&0&4]
>> Section start 2009/10/22 23:26:57.723
cmd: G:\Windows\system32\svchost.exe -k netsvcs
! dvi: Selecting driver failed(0xe0000228)
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for this device.
<<< Section end 2009/10/22 23:26:57.723
<<< [Exit status: FAILURE(0xe0000228)]
– Afterwards I started hdwwiz: –
>> [DIF_NEWDEVICEWIZARD_PRESELECT - ROOT\UNKNOWN\0000]
>> Section start 2009/10/22 23:29:26.412
cmd: “G:\Windows\system32\hdwwiz.exe”
<<< Section end 2009/10/22 23:29:26.412
<<< [Exit status: SUCCESS (DI_DO_DEFAULT)]
–rest of entries with “hdwwiz.exe” skipped, end log–
As said before: you don’t even get a chance to select a driver from/in the file system. New and interesting way of improving the user experience… 
Here is the last bit of inf\setupapi.dev.log from my Win7/RC1 machine:
–setupapi.dev.log–
[Boot Session: 2009/10/22 23:24:52.484]
>> [Device Install (Hardware initiated) - USB\VID_0xxx&PID_0002\5&12218da1&0&4]
>> Section start 2009/10/22 23:26:54.371
ump: Creating Install Process: DrvInst.exe 23:26:54.371
ndv: Retrieving device info…
ndv: Setting device parameters…
ndv: Searching just Driver Store…
dvi: {Build Driver List} 23:26:56.489
dvi: Searching for hardware ID(s):
dvi: usb\vid_0xxx&pid_0002&rev_0000
dvi: usb\vid_0xxx&pid_0002
dvi: Searching for compatible ID(s):
dvi: usb\class_00&subclass_00&prot_00
dvi: usb\class_00&subclass_00
dvi: usb\class_00
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list ‘G:\Windows\INF’
inf: Searched 0 potential matches in published INF directory
inf: Searched 35 INFs in directory: ‘G:\Windows\INF’
dvi: {Build Driver List - exit(0x00000000)} 23:26:56.614
ndv: Selecting best match from just Driver Store…
dvi: {DIF_SELECTBESTCOMPATDRV} 23:26:56.614
dvi: No class installer for ‘OurCompany Device USB Controller’
dvi: No CoInstallers found
dvi: Default installer: Enter 23:26:56.614
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for this device.
dvi: {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 23:26:56.629
ndv: Searching Windows Update for drivers… 23:26:56.661
ndv: Acquired WU search serialization mutex. 23:26:56.661
ndv: About to release WU search serialization mutex. 23:27:22.536
ndv: No driver found on Windows Update. 23:27:22.536
ndv: Searching Driver Store and Device Path…
dvi: {Build Driver List} 23:27:22.536
dvi: Searching for hardware ID(s):
dvi: usb\vid_0xxx&pid_0002&rev_0000
dvi: usb\vid_0xxx&pid_0002
dvi: Searching for compatible ID(s):
dvi: usb\class_00&subclass_00&prot_00
dvi: usb\class_00&subclass_00
dvi: usb\class_00
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list ‘G:\Windows\inf’
inf: Searched 0 potential matches in published INF directory
inf: Searched 35 INFs in directory: ‘G:\Windows\inf’
dvi: {Build Driver List - exit(0x00000000)} 23:27:22.770
ndv: Selecting best match from Driver Store (including Device Path)…
dvi: {DIF_SELECTBESTCOMPATDRV} 23:27:22.770
dvi: No class installer for ‘OurCompany Device USB Controller’
dvi: Default installer: Enter 23:27:22.770
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for this device.
dvi: {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 23:27:22.770
ndv: {Core Device Install}
! ndv: Installing NULL driver!
dvi: Set selected driver complete.
dvi: {DIF_ALLOW_INSTALL} 23:27:22.786
dvi: No class installer for ‘OurCompany Device USB Controller’
dvi: Default installer: Enter 23:27:22.786
dvi: Default installer: Exit
dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 23:27:22.786
dvi: {DIF_INSTALLDEVICE} 23:27:22.786
dvi: No class installer for ‘OurCompany Device USB Controller’
dvi: Default installer: Enter 23:27:22.786
! dvi: Installing NULL driver!
dvi: Writing common driver property settings.
dvi: {Restarting Devices} 23:27:22.817
dvi: Restart: USB\VID_0xxx&PID_0002\5&12218DA1&0&4
dvi: Restart complete.
dvi: {Restarting Devices exit} 23:27:23.004
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 23:27:23.020
ndv: Device install status=0xe0000203
ndv: Performing device install final cleanup…
! ndv: Queueing up error report since device installation failed…
ndv: {Core Device Install - exit(0xe0000203)}
ump: Server install process exited with code 0xe0000203 23:27:23.020
<<< Section end 2009/10/22 23:27:23.020
<<< [Exit status: FAILURE(0xe0000203)]
–end setupapi.dev.log–
(Yes, I changed the VID to 0xxx in the log, and replaced the company and device names.)
On 10/23/2009 4:51 PM, Doron Holan wrote:
what does the setup log say? what happens on W7 RTM?
>> [Device Install (Hardware initiated) -
USB\VID_0xxx&PID_0002\6&6ee641b&0&2]
>> Section start 2009/10/26 14:50:58.171
ump: Creating Install Process: DrvInst.exe 14:50:58.187
ndv: Retrieving device info…
ndv: Setting device parameters…
ndv: Searching Driver Store and Device Path…
dvi: {Build Driver List} 14:50:58.328
dvi: Searching for hardware ID(s):
dvi: usb\vid_0xxx&pid_0002&rev_0000
dvi: usb\vid_0xxx&pid_0002
dvi: Searching for compatible ID(s):
dvi: usb\class_00&subclass_00&prot_00
dvi: usb\class_00&subclass_00
dvi: usb\class_00
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list ‘C:\Windows\inf’
inf: Searched 0 potential matches in published INF directory
inf: Searched 35 INFs in directory: ‘C:\Windows\inf’
dvi: {Build Driver List - exit(0x00000000)} 14:50:58.718
ndv: Selecting best match from Driver Store (including Device Path)…
dvi: {DIF_SELECTBESTCOMPATDRV} 14:50:58.734
dvi: No class installer for ‘MyCompany Device USB Controller’
dvi: No CoInstallers found
dvi: Default installer: Enter 14:50:58.734
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
dvi: {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 14:50:58.734
ndv: {Core Device Install} 14:50:58.750
! ndv: Installing NULL driver!
dvi: Set selected driver complete.
dvi: {DIF_ALLOW_INSTALL} 14:50:58.750
dvi: No class installer for ‘MyCompany Device USB Controller’
dvi: Default installer: Enter 14:50:58.765
dvi: Default installer: Exit
dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 14:50:58.765
dvi: {DIF_INSTALLDEVICE} 14:50:58.765
dvi: No class installer for ‘MyCompany Device USB Controller’
dvi: Default installer: Enter 14:50:58.906
! dvi: Installing NULL driver!
dvi: Writing common driver property settings.
dvi: {Restarting Devices} 14:50:58.953
dvi: Restart: USB\VID_0xxx&PID_0002\6&6EE641B&0&2
dvi: Restart complete.
dvi: {Restarting Devices exit} 14:50:58.984
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 14:50:58.984
ndv: Device install status=0xe0000203
ndv: Performing device install final cleanup…
! ndv: Queueing up error report since device installation failed…
ndv: {Core Device Install - exit(0xe0000203)} 14:50:58.984
ump: Server install process exited with code 0xe0000203 14:50:59.000
<<< Section end 2009/10/26 14:50:59.015
<<< [Exit status: FAILURE(0xe0000203)]
Looks like with Windows 7, if you connect hardware that has no driver
pre-installed, the device is just not usable. You can manually open
device manager and “update” to a working driver from a subdirectory.
But that solution is not really user friendly.
Is this a bug, or is it clever design to not hassle users with the
tedious task of locating a driver on their PC?
> Is this a bug, or is it clever design to not hassle users with the
> tedious task of locating a driver on their PC?
>
I think it’s the design rather than a bug.
“Starting with Windows Vista, the core stages of device installation are
always run in a noninteractive, server-mode context.”
http://msdn.microsoft.com/en-us/library/ms791105.aspx
Hagen Patzke wrote:
On 10/23/2009 4:51 PM, Doron Holan wrote:
> what does the setup log say? what happens on W7 RTM?This is an excerpt from setupapi.dev.log from Win7/32/Ult/Retail:
>>> [Device Install (Hardware initiated) -
USB\VID_0xxx&PID_0002\6&6ee641b&0&2]
>>> Section start 2009/10/26 14:50:58.171
ump: Creating Install Process: DrvInst.exe 14:50:58.187
ndv: Retrieving device info…
ndv: Setting device parameters…
ndv: Searching Driver Store and Device Path…
dvi: {Build Driver List} 14:50:58.328
dvi: Searching for hardware ID(s):
dvi: usb\vid_0xxx&pid_0002&rev_0000
dvi: usb\vid_0xxx&pid_0002
dvi: Searching for compatible ID(s):
dvi: usb\class_00&subclass_00&prot_00
dvi: usb\class_00&subclass_00
dvi: usb\class_00
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list ‘C:\Windows\inf’
inf: Searched 0 potential matches in published INF directory
inf: Searched 35 INFs in directory: ‘C:\Windows\inf’
dvi: {Build Driver List - exit(0x00000000)} 14:50:58.718
ndv: Selecting best match from Driver Store (including Device Path)…
dvi: {DIF_SELECTBESTCOMPATDRV} 14:50:58.734
dvi: No class installer for ‘MyCompany Device USB Controller’
dvi: No CoInstallers found
dvi: Default installer: Enter 14:50:58.734
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
dvi: {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 14:50:58.734
ndv: {Core Device Install} 14:50:58.750
! ndv: Installing NULL driver!
dvi: Set selected driver complete.
dvi: {DIF_ALLOW_INSTALL} 14:50:58.750
dvi: No class installer for ‘MyCompany Device USB Controller’
dvi: Default installer: Enter 14:50:58.765
dvi: Default installer: Exit
dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 14:50:58.765
dvi: {DIF_INSTALLDEVICE} 14:50:58.765
dvi: No class installer for ‘MyCompany Device USB Controller’
dvi: Default installer: Enter 14:50:58.906
! dvi: Installing NULL driver!
dvi: Writing common driver property settings.
dvi: {Restarting Devices} 14:50:58.953
dvi: Restart: USB\VID_0xxx&PID_0002\6&6EE641B&0&2
dvi: Restart complete.
dvi: {Restarting Devices exit} 14:50:58.984
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 14:50:58.984
ndv: Device install status=0xe0000203
ndv: Performing device install final cleanup…
! ndv: Queueing up error report since device installation failed…
ndv: {Core Device Install - exit(0xe0000203)} 14:50:58.984
ump: Server install process exited with code 0xe0000203 14:50:59.000
<<< Section end 2009/10/26 14:50:59.015
<<< [Exit status: FAILURE(0xe0000203)]Looks like with Windows 7, if you connect hardware that has no driver
pre-installed, the device is just not usable. You can manually open
device manager and “update” to a working driver from a subdirectory.
But that solution is not really user friendly.Is this a bug, or is it clever design to not hassle users with the
tedious task of locating a driver on their PC?
Hagen Patzke wrote:
> Is this a bug, or is it clever design to not hassle users with the
> tedious task of locating a driver on their PC?
Philip Ries wrote:
I think it’s the design rather than a bug.
“Starting with Windows Vista, the core stages of device installation are
always run in a noninteractive, server-mode context.”
http://msdn.microsoft.com/en-us/library/ms791105.aspx
Thanks Philip, for the very interesting pointer!
But the statement has to read “Starting with Windows 7…” then.
On Vista, plug-in of a new(*) device *does* prompt the user with an
installation dialog - I verified this for 32 and 64bit versions.
Hm… of course Microsoft has the right and the means to enforce any
type of device driver pre-installation they like. The next logical step
after mandatory driver pre-install (introduced with Windows 7) could be
installation of inbox and “Windows Update”-distributed drivers only.
(This nicely enforces WHQL-signing for all drivers. )
This would be more secure and also gives a better user experience.
(*) any not “in-box” and not HID/MSD device only
Yes, it’s by design. See Scenario 5 in the Winhec 2008 presentation on Win7 Device Installation Experience:
http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/CON-T532_WH08.pptx
On 10/27/2009 7:17 PM, xxxxx@smsc.com wrote:
Yes, it’s by design. See Scenario 5 in the Winhec 2008 presentation on Win7 Device Installation Experience:
http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/CON-T532_WH08.pptx
Thanks for providing the answer to my question!
DPinst works well. The only thing which would be nice is to have a
multi-platform version of it (the driver package is multi-platform, it
would be nice if the device pre-installer could be as well).
Any input about this?
“This behavior is by design.” (http://support.microsoft.com/kb/950161/en-us)
There are x86, x64 and ia64 versions of the DPInst app and you can crete a multiplatform installer (at least for x86 & x64) using them. Look at this whitepaper for details:
http://www.microsoft.com/whdc/driver/install/32-64bit_install.mspx
I have used DPInst for several of my drivers. It does indeed give you a quick way to provide a friendly installer for people (like me) who live in the kernel and are alergic to user mode apps. Be aware though that you will most likely encounter some problems (most notably with its uninstallation feature in “Add/Remove Programs” in XP, or “Programs and Features” in Vista/Win7, which I ended up disabling) with it.
xxxxx@smsc.com wrote:
There are x86, x64 and ia64 versions of the DPInst app and you can crete a multiplatform installer (at least for x86 & x64) using them. Look at this whitepaper for details:
http://www.microsoft.com/whdc/driver/install/32-64bit_install.mspxI have used DPInst for several of my drivers. It does indeed give you a quick way to provide a friendly installer for people (like me) who live in the kernel and are alergic to user mode apps. Be aware though that you will most likely encounter some problems (most notably with its uninstallation feature in “Add/Remove Programs” in XP, or “Programs and Features” in Vista/Win7, which I ended up disabling) with it.
It’s interesting you would say that. My experience with DPInst and
uninstalling has been almost entirely positive, on XP, Vista, and Win
7. It just works the way I think it should.
My normal driver delivery scheme now consists of a very simple NSIS
installation script that invokes DPInst, both on the way in and out.
It’s simple and painless.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, here’s one example of the problems I encountered:
Using KMDF <=1.7 when running under Vista (same was happening with early Win7 test versions), if I started the uninstall from the “Programs and Features” entry that DPInst created during installation it looked like everything worked fine (entry dissapeared from “Programs and Features”) but the device remained installed and working.
I opened a case with MSFT Premier support on May 2008 and they confirmed this was a problem after repro-ing it with the toaster sample. The issue was in the in the WDFCoinstaller. It was only fixed more than a year later when the official KMDF 1.9 coinstaller shipped with Win7 RTM.
I reported a few other (less critical) issues as well, but those affected DPInst itself and I was told that I should not expect a fix anytime soon (apparently the MSFT team that created DPInst is gone and nobody is supporting it now).
On 10/28/2009 10:05 PM, xxxxx@smsc.com wrote:
There are x86, x64 and ia64 versions of the DPInst app and you can
crete a multiplatform installer (at least for x86 & x64) using them.
Look at this whitepaper for details:
http://www.microsoft.com/whdc/driver/install/32-64bit_install.mspx
Thanks for the pointer - very helpful and interesting read!
Of course, the procedure itself is a little bit sad: DPinst is not an
integral part of the OS, also there is no DPinst multi-platform binary
that works for 32/64bit.
The driver developer has to write a mini-program to detect the platform
that invokes the correct DPinst version. (?!)
At least this should not be very painful: thanks to WHDC for providing
information and sample code!
I have used DPInst for several of my drivers. […] Be aware though
that you will most likely encounter some problems (most notably with
its uninstallation feature in “Add/Remove Programs” in XP, or
“Programs and Features” in Vista/Win7, which I ended up disabling)
with it.
Thanks for the warning! One issue I’ve seen once during deinstallation
(on a WinXP test machine) was a prompt for a missing *.sys file in a
nonexistent directory. So this was not just a glitch…
Hagen Patzke wrote:
On 10/28/2009 10:05 PM, xxxxx@smsc.com wrote:
Of course, the procedure itself is a little bit sad: DPinst is not an
integral part of the OS, also there is no DPinst multi-platform binary
that works for 32/64bit.
Yes, but on the other hand, you need different driver files for 32/64
bit as well. And even though DPinst is not part of the OS, it certainly
is an integral tool in the WDK, and you are given permission to
redistribute it.
The fact is that, for better or worse, most major corporations will want
to do branding on their installation scripts anyway. They won’t want to
use DPinst as-is.
The driver developer has to write a mini-program to detect the platform
that invokes the correct DPinst version. (?!)
Right – that’s what I use NSIS for. You have to think about how you
will deploy your drivers. Do you intend to just ship a zip file, and
force the user to unzip it and point Device Manager at the unzipped
directory? That’s not very friendly. Generally, you’re going to need
something to oversee the installation.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.