ordered device/user client tear down

NTDEV
1

Hi,
beneath others my driver registers an EvtDeviceReleaseHardware and an EvtFileCleanup handler registered to the devices file objects with WdfDeviceInitSetFileObjectConfig.

My application registers DBT_DEVICEQUERYREMOVE, DBT_DEVICEREMOVEPENDING or DBT_DEVICEREMOVECOMPLETE and closes its open handles to the drivers upon receive.

When unloading or disabling the driver while a user client still has a file object to the driver open the tear down sequence is as expected:

  1. EvtFileCleanup
  2. EvtDeviceReleaseHardware
    This allows to turn down user client stuff while still be able to access the device

At surprise removal (USB or 1394) the order is inverse:

  1. EvtDeviceReleaseHardware
  2. EvtFileCleanup
    This makes it complicated to keep track of the object dependencies. Well, not complicated but adds pit falls and additional order checks.

Is there a way to enforce to close file objects before handling EvtDeviceReleaseHardware?

Thanks and best regards,
Hagen.

2

> 1. EvtDeviceReleaseHardware

  1. EvtFileCleanup
    This makes it complicated to keep track of the object dependencies. Well, not complicated but adds
    pit falls and additional order checks.

What kind of them?

It should not.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

3

No, you can’t enforce the order. This is why surprise removal exists, your device is gone but there are still handles open, but we need to partially tear down the stack’s state.

d

Bent by my phone

From: xxxxx@dynax.atmailto:xxxxx
Sent: ?10/?2/?2013 2:00 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] ordered device/user client tear down

Hi,
beneath others my driver registers an EvtDeviceReleaseHardware and an EvtFileCleanup handler registered to the devices file objects with WdfDeviceInitSetFileObjectConfig.

My application registers DBT_DEVICEQUERYREMOVE, DBT_DEVICEREMOVEPENDING or DBT_DEVICEREMOVECOMPLETE and closes its open handles to the drivers upon receive.

When unloading or disabling the driver while a user client still has a file object to the driver open the tear down sequence is as expected:
1. EvtFileCleanup
2. EvtDeviceReleaseHardware
This allows to turn down user client stuff while still be able to access the device

At surprise removal (USB or 1394) the order is inverse:
1. EvtDeviceReleaseHardware
2. EvtFileCleanup
This makes it complicated to keep track of the object dependencies. Well, not complicated but adds pit falls and additional order checks.

Is there a way to enforce to close file objects before handling EvtDeviceReleaseHardware?

Thanks and best regards,
Hagen.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

4

Surprise removal MUST NOT tear the driver structures. It only should flag them as not accepting any new I/O requests, and also cancel any requests in progress.

5

Thanks, for the clarification!