Author Topic: how to avoid Windows reboot warnings after HID first plugged in  (Read 8870 times)

phadley

  • Member
  • ***
  • Posts: 6
how to avoid Windows reboot warnings after HID first plugged in
« on: February 11, 2011, 01:58:05 pm »
We make a custom HID device, and we use the standard HID device drivers
provided by Microsoft to talk to it. Our device shows up in the Device
Manager as a USB Human Interface Device. Each of our devices reports a unique
serial number during USB enumeration.

The first time that a specific device with a given serial number is plugged
in on an XP system, there is a delay as the system finds the device drivers
for the device. If this device is unplugged and then replugged in later,
there is no noticeable delay after plugging in.

If our application is running when the device is plugged in, we process
WM_DEVICE_CHANGE messages, and look for what is plugged in by running code
that calls dynSetupDiGetClassDevs, etc. to walk the device database looking
for devices with our USB vendor and product ID's. We also check that the
SPDRP_CONFIGFLAGS property is set in an attempt to verify that installation
for the device is complete. If we find a device matching these criteria, we
open it and start communicating with it.

Sometimes, we get messages from Windows warning us that we need to reboot.
This only happens if our app is running and we have opened a device that was
just plugged in for the first time. I believe that we are opening the device
before Windows has finished with the HID device driver initialization for the
device.

How can we avoid getting the reboot warnings from Windows?


Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: how to avoid Windows reboot warnings after HID first plugged in
« Reply #1 on: February 12, 2011, 09:43:23 am »
It's possible that the device firmware isn't responding correctly to communications that occur quickly after enumeration completes. For example, the interrupt IN endpont should be ready to ACK or NAK IN token packets.

A protocol analyzer would show exactly what is happening on the bus.

Jan

phadley

  • Member
  • ***
  • Posts: 6
Re: how to avoid Windows reboot warnings after HID first plugged in
« Reply #2 on: February 14, 2011, 04:57:59 pm »
Reporting back on my progress:

I discovered that my software was querying the device too quickly and without checking the device's install state.

Lessons learned:

1) When the DBT_DEVICEARRIVAL message arrives in my WndProc override, don't attempt to query the device directly until the install state is "installed" via the SPDRP_INSTALL_STATE device registry property.

2) Examples of offending device queries that cause the reboot warning if performed before the device is installed:

HidD_GetSerialNumberString
HidD_GetManufacturerString
HidD_GetProductString
HidD_GetAttributes
HidD_GetPreparsedData
HidP_GetSpecificValueCaps
HidP_GetCaps


3) Examples of non-offending externs that are useful to determine whether or not you care about the device:

SetupDiGetClassDevs
SetupDiEnumDeviceInterfaces
SetupDiGetDeviceInterfaceDetail
SetupDiGetDeviceRegistryProperty
SetupDiDestroyDeviceInfoList


Thanks, Jan.

Phil

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: how to avoid Windows reboot warnings after HID first plugged in
« Reply #3 on: February 14, 2011, 10:24:20 pm »
Interesting. Thanks for sharing what you learned.

Jan

mdlayt

  • Member
  • ***
  • Posts: 40
Re: how to avoid Windows reboot warnings after HID first plugged in
« Reply #4 on: February 16, 2011, 03:57:09 pm »
Very interesting.

I have always thought that the "reboot" message was either because the driver install asked for it, or because Windows thinks (or knows) that it isn't possible to fully install the driver (including removing a previous driver) except at boot (eg a PS2 driver).  These cases seem to be "something bad happened on the way to the installation" so "shutup and reboot" and hopefully it won't happen next time.

At first glance, it appears that the HID driver doesn't know what it is doing.  Why can't it just fail all the calls until the device finishes installing?  (Or maybe just not return a handle to it until it is actually available, or whatever.)

If only someone from Microsoft could come on and explain all this for us.