none
atapi.sys safe remove of compact flash device RRS feed

  • Question

  • We are developing Windows (Vista +) support for our compact flash media reader, which is based on a PCIe to IDE controller. Customers would like to insert and remove the media and have the system notice without having to go to the device manager and "scan for hardware changes". We would like this work regardless of whether the media is marked "removable" or not in its IDENTIFY data.

    We have developed a mechanism to detect the insertion and removal of the devices, but we would also like to either:

    1) disable write caching, so the CF can be surprise ejected or

    2) enable safe removal on the media.

    Atapi.sys doesn't seem to support either of these requirements by default. A disk.sys filter driver will probably work, but it will then load for all storage devices in the system, which seems clumsy. A custom ATAPort miniport driver will work, but that seems like a lot of effort.

    Any better ideas?

    Henry Kannapell Sonnet Technologies, Inc

    Tuesday, September 24, 2013 3:22 PM

All replies

  • You should be able to query the device from an AddDevice routine in a disk.sys filterusing IOCTL_STORAGE_QUERY_PROPERTY and only attach to the devices that are yours.  I've done this for several clients over the years.  You could also just use IoGetDeviceProperty to check for your PCI ID.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    • Marked as answer by Doron Holan [MSFT] Tuesday, September 24, 2013 8:59 PM
    • Unmarked as answer by hkannapell Monday, November 4, 2013 9:27 PM
    Tuesday, September 24, 2013 3:29 PM
  • We have found a method to mark the CF disks as removable, but now we would like them to appear in Windows "Safely Remove Hardware and Eject Media" list.

    We could get the disks listed by patching into the IRP_MJ_PNP's IRP_MN_QUERY_CAPABILITIES and modifying the Removable capabilities in a completion routine, but it seems whenever a IRP_MN_QUERY_DEVICE_RELATIONS gets sent (for example, by a "Scan for hardware changes"), the devices are no longer safely removable.

    Any ideas as to why this is happening and how to work around it?


    Henry Kannapell Sonnet Technologies, Inc

    • Marked as answer by Doron Holan [MSFT] Monday, November 4, 2013 11:26 PM
    • Unmarked as answer by hkannapell Wednesday, November 6, 2013 3:06 PM
    Monday, November 4, 2013 9:33 PM
  • You need to clear SurpriseRemovalOK for it to show up in the UI.  you have to set this each time you receive a QUERY_CAPABILITIES

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, November 4, 2013 11:25 PM
  • We already do this. It works, until a QUERY_DEVICE_RELATIONS gets received. Here's some more clarification on what we have currently:

    We are using a disk.sys upper filter driver that primarily does two things:

    1) Adds a completion routine for IOCTL_STORAGE_QUERY_PROPERTY that sets the RemovableMedia bit in the STORAGE_DEVICE_DESCRIPTOR

    2) Adds a completion routine for IRP_MN_QUERY_CAPABILITIES that sets the Removable capability to 1 and the SurpriseRemovalOK capability to 0.

    By the combination of these two efforts, we can get the CF disk's friendly name (eg. "SanDisk SDCFH-004G") to show in the UI. You can successfully safely remove this disk by selecting it in the Safely Remove Hardware list. However, if you do not safely remove the disk, whenever a IRP_MN_QUERY_DEVICE_RELATIONS gets received by the filter driver, the CF disk's friendly name changes to the CF disk's volume name (eg. "ULTRA (E:)"). If you then try to safely remove the disk by clicking the volume name, you get a pop-up error that says "An error occurred while ejecting 'ULTRA (E:)'". The filter driver does not do anything with the QUERY_DEVICE_RELATIONS - it passes it down to the disk driver. We even put in a test to re-send a QUERY_CAPABILITIES IRP to re-set the capabilities values, but this does not nothing.

    The association with the friendly-name-to-volume-name event and the IRP_MN_QUERY_DEVICE_RELATIONS may be coincidental, but we can manually cause this name change event to happen by performing a manual "Scan for Hardware Changes" in the Device Manager.


    Henry Kannapell Sonnet Technologies, Inc

    Wednesday, November 6, 2013 3:06 PM