RE: SOLVED: AddDevice is called between IRP_MN_SURPRISE_REMOVAL and IRP_MN_REMOVE_DEVICE

NTDEV
1

Hi!

Problem solved: I accidentally called IoSetDeviceInterfaceState with
“FALSE” twice. Once in SURPRISE_REMOVAL and once in REMOVE_DEVICE.
This had interfered with AddDevice().

Daniel

Hi!

I am writing a driver for my USB device and I am experiencing problems
with a firmware-based reattachment of the device.

When the device is disconnected manually and plugged-in again,
everything works fine.

But if the device is disconnected and reconnected very fast due to a
hardware-based reset while the device is still connected to the PC,
I get the following sequence:

  1. IRP_MN_SURPRISE_REMOVAL
  2. AddDevice()
  3. IRP_MN_START_DEVICE
  4. IRP_MN_REMOVE_DEVICE

Afterwards the device is present in the device manager, but cannot be
accessed until it is reconnected again.

I experienced this under XP SP2 and Vista.

Daniel

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

2

Daniel Boldt wrote:

I am writing a driver for my USB device and I am experiencing problems
with a firmware-based reattachment of the device.

When the device is disconnected manually and plugged-in again,
everything works fine.

But if the device is disconnected and reconnected very fast due to a
hardware-based reset while the device is still connected to the PC,
I get the following sequence:

  1. IRP_MN_SURPRISE_REMOVAL
  2. AddDevice()
  3. IRP_MN_START_DEVICE
  4. IRP_MN_REMOVE_DEVICE

Afterwards the device is present in the device manager, but cannot be
accessed until it is reconnected again.

What do you mean by “cannot be accessed?” I can tell you one common
scenario that will fail like this. If you are using an FX2 chip (as the
“firmware-based reattachment” implies), then you may be using a driver
based on the “ezusbsys” sample provided by Cypress. That sample creates
a symbolic link called \.\Ezusb-0 for user-mode programs to open. That
final digit gets incremented based on the number of devices currently
active.

In the scenario you describe, the new device instance in step 3 will
create \.\EzUsb-1, and the closing of the old device will kill
\.\EzUsb-0. If your application is hardcoded to open \.\EzUsb-0, then
it will fail.

The answer in that case is to have the driver register itself in a
device interface, and use the SetupDi tools to enumerate all of the
devices that expose your private interface. That way, you’ll get
whatever happens to be available, no matter what order they were created.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.