Anyone hit the problem with common HID device and Windows 7?
The device works well on Vista and XP, os builtin hid driver’s are installed correctly.
The same device on Win7 produces this error.
Checking the setupapi.dev.log i could seen that the first communication with the device works well, the hid drivers are installed and the error shows up only after that (no details just error).
Here is is the last part of the setupapi.dev.log:
inf: {Install Inf Section [HID_Inst.NT]}
inf: {Install Inf Section [HID_Inst.NT] exit (0x00000000)}
inf: {Install Inf Section [HID_Inst.NT.Hw]}
inf: DelReg=HID_Inst.DelReg.NT.HW (input.inf line 492)
inf: {Install Inf Section [HID_Inst.NT.Hw] exit (0x00000000)}
dvi: {Writing Device Properties}
dvi: Provider name=Microsoft
dvi: DriverDate 06/21/2006
dvi: DriverVersion=6.1.7600.16385
dvi: Class name=HIDClass
dvi: Manufacturer=(Standard system devices)
dvi: Matching DeviceID=generic_hid_device
dvi: Strong Name=input.inf:Standard.NTamd64:HID_Inst:6.1.7600.16385::generic_hid_device:usb\class_03&subclass_01:usb\class_03
dvi: Additional Software Requested
dvi: {Writing Device Properties - Complete}
inf: {Install Inf Section [HID_Inst.NT.Services]}
inf: AddService=HidUsb,0x00000002,HID_Service_Inst (input.inf line 504)
inf: ServiceType=1 (input.inf line 520)
inf: StartType=3 (input.inf line 521)
inf: ErrorControl=0 (input.inf line 522)
inf: ServiceBinary=C:\Windows\system32\DRIVERS\hidusb.sys (input.inf line 523)
inf: DisplayName=“Microsoft HID Class Driver” (input.inf line 519)
inf: LoadOrderGroup=“extended base” (input.inf line 524)
dvi: Add Service: Modified existing service ‘HidUsb’.
inf: {Install Inf Section [HID_Inst.NT.Services] exit(0x00000000)}
dvi: Updated reflected section names for: input.inf
dvi: {Install DEVICE exit (0x00000000)}
dvi: Writing common driver property settings.
dvi: DriverDescription=USB Input Device
dvi: DeviceDisplayName=USB Input Device
dvi: Install Device: Restarting device. 11:00:38.645
dvi: Install Device: Restarting device completed. 11:00:38.676
!!! dvi: Device not started: Device has problem: 0x0a: CM_PROB_FAILED_START.
dvi: Default installer: Exit
CM_PROB_FAILED_START generally occurs when the system is unable to load your
image (corrupt binary, unmet dependency etc). I generally start with
depends.exe
to see if there are any problems there.But hidusb.sys is inbox so there
should not be any problems of this sort (try replacing it from the
installation media?).
Does this error occur on all HID devices (redundant I know) or just your
one?
On Thu, Aug 26, 2010 at 1:55 AM, wrote:
> Hi > > Anyone hit the problem with common HID device and Windows 7? > > The device works well on Vista and XP, os builtin hid driver’s are > installed correctly. > The same device on Win7 produces this error. > > Checking the setupapi.dev.log i could seen that the first communication > with the device works well, the hid drivers are installed and the error > shows up only after that (no details just error). > > Here is is the last part of the setupapi.dev.log: > inf: {Install Inf Section [HID_Inst.NT]} > inf: {Install Inf Section [HID_Inst.NT] exit > (0x00000000)} > inf: {Install Inf Section [HID_Inst.NT.Hw]} > inf: DelReg=HID_Inst.DelReg.NT.HW (input.inf > line 492) > inf: {Install Inf Section [HID_Inst.NT.Hw] exit > (0x00000000)} > dvi: {Writing Device Properties} > dvi: Provider name=Microsoft > dvi: DriverDate 06/21/2006 > dvi: DriverVersion=6.1.7600.16385 > dvi: Class name=HIDClass > dvi: Manufacturer=(Standard system devices) > dvi: Matching DeviceID=generic_hid_device > dvi: Strong > Name=input.inf:Standard.NTamd64:HID_Inst:6.1.7600.16385::generic_hid_device:usb\class_03&subclass_01:usb\class_03 > dvi: Additional Software Requested > dvi: {Writing Device Properties - Complete} > inf: {Install Inf Section [HID_Inst.NT.Services]} > inf: > AddService=HidUsb,0x00000002,HID_Service_Inst (input.inf line 504) > inf: ServiceType=1 (input.inf line 520) > inf: StartType=3 (input.inf line 521) > inf: ErrorControl=0 (input.inf line 522) > inf: > ServiceBinary=C:\Windows\system32\DRIVERS\hidusb.sys (input.inf line 523) > inf: DisplayName=“Microsoft HID Class Driver” > (input.inf line 519) > inf: LoadOrderGroup=“extended base” > (input.inf line 524) > dvi: Add Service: Modified existing service > ‘HidUsb’. > inf: {Install Inf Section [HID_Inst.NT.Services] > exit(0x00000000)} > dvi: Updated reflected section names for: input.inf > dvi: {Install DEVICE exit (0x00000000)} > dvi: Writing common driver property settings. > dvi: DriverDescription=USB Input Device > dvi: DeviceDisplayName=USB Input Device > dvi: Install Device: Restarting device. 11:00:38.645 > dvi: Install Device: Restarting device completed. > 11:00:38.676 > !!! dvi: Device not started: Device has problem: 0x0a: > CM_PROB_FAILED_START. > dvi: Default installer: Exit > > — > 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 >
Perhaps shouldn’t jump in out of context, but CM_PROB_FAILED_START is actually fairly specific- it means the start processing failed- i.e. the driver loaded, passed DriverEntry and AddDevice, but failed (almost always- not sure what happens if you fail [or even can fail] requirements filtering, etc, and don’t intend to look it up atm) IRP_MN_START_DEVICE.
I’m fairly (95+%) certain (not having time to do a live experiment, and not having encountered it in the last couple of weeks to keep it fresh) that a failure to load the image is code 39- CM_PROB_DRIVER_FAILED_LOAD.
There are also specific codes for failing DriverEntry (37) and AddDevice (31).
You are right… I got mixed up with CM_PROB_DRIVER_FAILED_LOAD
On Thu, Aug 26, 2010 at 9:42 AM, Bob Kjelgaard wrote:
> Perhaps shouldn?t jump in out of context, but CM_PROB_FAILED_START is > actually fairly specific- it means the start processing failed- i.e. the > driver loaded, passed DriverEntry and AddDevice, but failed (almost always- > not sure what happens if you fail [or even can fail] requirements filtering, > etc, and don?t intend to look it up atm) IRP_MN_START_DEVICE. > > > > I?m fairly (95+%) certain (not having time to do a live experiment, and not > having encountered it in the last couple of weeks to keep it fresh) that a > failure to load the image is code 39- CM_PROB_DRIVER_FAILED_LOAD. > > There are also specific codes for failing DriverEntry (37) and AddDevice > (31). > > > > — > 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 >
Bob is right - it’s device related - the drivers are installing, the error is given after installation when device is restarted. And it happens on at least 2 Windows7 installations so most probably happens with all.
It does not happen with all HID devices - tried a few other ones and they are working.
What is strange that the same device works very well on XP and Vista so it’s something changed in Windows 7 in how it deals with the device when it’s restarted. This is what I wanted to know if anyone knows anything about this … Could be that device does not restarts fast enough?
I foresee a dark perspective of logging all USB messages with a sniffer to see what goes wrong there - hoping that it’s a USB message and it’s not a short timeout in Windows 7 …
It seems it’s related with the speed of queries - Win7 asks for descriptor table with less <1msec between them (we got 800 microsec or less in many cases in the logger).
Sometimes in the case of slower devices those one cannot handle the 3rd, 4th request. In this case Windows 7 will report error 10 and fail.
Same requests on XP are a few milliseconds long so it’s not a problem (though our XP tests systems are slower too so this can also influence).
I’ve seen this error on forums with other devices too so it’s not a unic problem … Lot’s of HID devices cannot handle <1 msec gap between requests (HID standard) so this will cause many complaints …
I know this section of the requests is not HID (it’s the USB descriptor table) but still those devices are too slow to answer with that speed …