Drive discovery issue with lower filter driver

[Dennis Ginley]

I'm a software engineer in a storage group, working on a disk IO tracing
tool. My tool installs a lower filter driver into the storage stack. I have a
problem with USB drives not being discovered after my driver is loaded.

Here are the repro steps for what I'm seeing.
Do a clean install of Win 7 or Vista, 32 or 64 bits.
Install the app.
Install the driver.
Reboot to load the driver.
Plug in a USB drive that has not been plugged into the system before.
A message is shown saying "Device driver software was not successfully
installed" and the USB drive has a yellow bang in Device Manager.

Plug in a USB drive that has been plugged into the system before.
That drive is recognized, and can be read and written.

Uninstall the lower filter driver
Reboot to unload the driver.
Plug in any USB drive.
That drive is recognized, and can be read and written.

Note that this is not the "disappearing DVD" issue. Throughout the above
process the DVD is usable.

Some more info on this problem. I built a debug driver and got Windbg
working. I learned that when I plug in an "old" USB drive, my AddDevice()
function gets called, but when I plug in a "new" drive it does not. That
immediately suggested the registry, so I opened regedit and plugged in an
"old" drive, then searched the registry for it. I found entries in these keys:

HKLM\Software\Microsoft\WBEM\WDM
HKLM\Software\Microsoft\WBEM\WDM\DREDGE
HKLM\Software\Microsoft\Windows NT\CurrentVersion\EMDMgmt
HKLM\Software\Microsoft\Windows Portable Devices\Devices
HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses (5 entries)
HKLM\SYSTEM\CurrentControlSet\Enum\STORAGE\Volume
HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR
HKLM\SYSTEM\CurrentControlSet\Enum\WpdBusEnumRoot\UMB
HKLM\SYSTEM\CurrentControlSet\services\Disk\Enum
HKLM\SYSTEM\CurrentControlSet\services\fvevol\Enum
HKLM\SYSTEM\CurrentControlSet\services\ntwiot5\Enum
HKLM\SYSTEM\CurrentControlSet\services\partmgr\Enum
HKLM\SYSTEM\CurrentControlSet\services\rdyboost\Enum
HKLM\SYSTEM\CurrentControlSet\services\volsnap\Enum
HKLM\SYSTEM\CurrentControlSet\services\WUDFRd\Enum

plus some in ControlSet001 and ControlSet002

Then I did the same thing with a "new" drive and found only three entires:
HKLM\SYSTEM\CurrentControlSet\services\Disk\Enum
HKLM\SYSTEM\CurrentControlSet\services\ntwiot5\Enum
HKLM\SYSTEM\CurrentControlSet\services\partmgr\Enum

plus some in ControlSet001 and ControlSet002


It seems like a chicken and egg situation, where the driver isn't loaded
because there's a registry entry missing, but the registry isn't being
written because the lower filter is present.

Thanks,
Dennis

[Don Burn]

Are you filtering and properly handling the various IRP_MJ_PNP calls
especially IRP_MN_QUERY_DEVICE_RELATIONS. If your filter is a low as I
believe you are essentially a bus filter and you have to handle these
correctly. This is tricky since when you see the
IRP_MN_QUERY_DEVICE_RELATIONS you need to discover the changes in the PDO's
and do the right thing.

--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"Dennis Ginley" <Dennis...@discussions.microsoft.com> wrote in message
news:01B3841E-2FC1-4E1E...@microsoft.com...

> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4558 (20091030) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4558 (20091030) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Dennis Ginley]

Don, thanks for the reply and suggestion. I added a handler, basically a
stub, for
IRP_MN_QUERY_DEVICE_RELATIONS, but since my AddDevice is never called, I
never see the device at all.

I'm thinking that my driver is not being installed as a filter for USB mass
storage devices, so I'm investigating how to do that now.

Dennis

[Brian Catlin [MVP]]

"Dennis Ginley" <Dennis...@discussions.microsoft.com> wrote in message
news:01B3841E-2FC1-4E1E...@microsoft.com...

Based upon the symptoms you're reporting, you're not passing down the PNP
enumeration IRPs properly. It isn't clear to me where you want to be
loaded. Are you trying to create a lower-level Function Filter Device
Object (FFDO) or a Bus Filter Device Object (BFDO)?

-Brian

Brian Catlin, Azius Developer Training, 888-238-4050 x4
Windows device driver training and consulting
See www.azius.com for a list of classes

[Dennis Ginley]

I'm a lower filter, sitting just below the storage class driver. My AddDevice
is called for hard disks, CDs, and for USB keys that were inserted into the
test box before my driver was installed, but not for "new" USB dirves. So new
drives don't ever get added to my list of things to filter, and in fact the
system doesn't even load drivers for them.

So technically it's true that I'm not passing down any IRPs, because I'm not
seeing them.

[Brian Catlin [MVP]]

From your description, it would appear that the PNP enumeration IRPs
(QUERY_*) are not being processed correctly. Without seeing the code and
the INF file, I cannot be more precise. Which OS are you testing on? Can
you enable the PNP debug spew in the debugger?

-Brian

Brian Catlin, Azius Developer Training, 888-238-4050 x4
Windows device driver training and consulting
See www.azius.com for a list of classes

"Dennis Ginley" <Dennis...@discussions.microsoft.com> wrote in message

news:4B4A8F10-6AA4-477A...@microsoft.com...

[Dennis Ginley]

I turned on debug spew and got the following:

When I plug in and then remove a USB drive that has been seen before my
driver installation,
NTWIOT5: *AddDevice() entered [pdo=028DA060].
NTWIOT5: Attached to device [hookDev=03172040] [targetDev=03037E00].
NTWIOT5: *DispatchPnp(IRP_MN_START_DEVICE) entered [03172040].
NTWIOT5: *PnpStartDevice() entered [03172040].
NTWIOT5: NtioInitializeHook() entered [03172040].
NTWIOT5: *DispatchPnp(IRP_MN_REMOVE_DEVICE) entered [03172040].
NTWIOT5: *PnpRemoveDevice() entered [03172040].

When I plug in a "new" USB drive, i.e. one that had not been plugged in
before the driver was installed, I see no spew at all.

I added stubs for the QUERY_*) as Brian suggested, but since my driver is
never entered for a new device, none of them are ever hit.

It really seems like the presence of my lower filter is interfering with the
PNP process.

I'm attaching to the DiskDrive and CDROM classes in
HKLM/System/CurrentControlSet/Control/Class/... Is there some other way to
attach as a lower filter to USB removable devices?

Thanks,
Dennis

[David Craig]

Is this a new install of the OS on the target system? I have found that XP
after about a year will not see a new USB stick even where other, previously
seen ones, are currently working. Just Windows rot.

"Dennis Ginley" <Dennis...@discussions.microsoft.com> wrote in message

news:AB798903-7257-482E...@microsoft.com...

[Dennis Ginley]

I enabled debug spew as Brian suggested.

When I insert and then remove a USB drive that had been installed in the
test system before my lower filter was installed, this is what I see:

NTWIOT5: *AddDevice() entered [pdo=028DA060].
NTWIOT5: Attached to device [hookDev=03172040] [targetDev=03037E00].
NTWIOT5: *DispatchPnp(IRP_MN_START_DEVICE) entered [03172040].
NTWIOT5: *PnpStartDevice() entered [03172040].
NTWIOT5: NtioInitializeHook() entered [03172040].
NTWIOT5: *DispatchPnp(IRP_MN_REMOVE_DEVICE) entered [03172040].
NTWIOT5: *PnpRemoveDevice() entered [03172040].

When I insert a "new" USB drive, i.e. one that had not been insterted into
the test system before installing the filter driver, there is no spew at all.
On the test box I see a message that the system is loading a driver, then
another that the driver load failed.

I also created stubs for the (QUERY_*) PNP enumeration IRPs, but none of
them were ever hit. It seems as if the presence of the lower filter driver is
interfering with the PNP process itself.

I'm attaching to the Disk Drive and CD_ROM classes in
HKLM/System/CurrentControlSet/Control/Class... Is there another place to
attach so I see USB drive discovery IRPs?

Thanks,
Dennis

[Dennis Ginley]

I'd like to report that I figured it out, or at least I got it working. After
almost three weeks of research and trying different things, I discovered that
I needed to add the key "ErrorControl = 1" to
HKLM\System\CurrentControlSet\Services\ntwiot5.

I really don't know why that fixed the problem, but it did. This tool has
existed for ten years as an upper filter without that key, but when I
switched it to a lower filter it broke. With that key in place, all USB
drives are recognized, and drivers are loaded for them.

Thanks for the help and suggestions,
Dennis

[spanner]

Hi, i am having the same problem with my USB storagedevises.
Is it at all possible to explain in detail how to do this.