Hello,
I have an issue that I was hoping you experts can offer some guidance on.
I have built a UMDF driver and we noticed that it does not unload properly if we disable it. When we disable, we don’t see any tracing and I think the driver stays loaded to Windows. If I re-enable, makes the driver work again as expected, but in the tracing we don’t see DriverEntry call, which seems that the driver is still loaded from before.
I want to break in with a WinDbg, but I don’t sure what to look for here. I am newer to WinDbg.
Would you be able to advise?
Thank you!
Charles
xxxxx@gmail.com wrote:
I have an issue that I was hoping you experts can offer some guidance on.
I have built a UMDF driver and we noticed that it does not unload properly if we disable it. When we disable, we don’t see any tracing and I think the driver stays loaded to Windows. If I re-enable, makes the driver work again as expected, but in the tracing we don’t see DriverEntry call, which seems that the driver is still loaded from before.
What kind of device is this? Remember that the driver will not be
unloaded if there are any open handles. So, if you have an application
with an open file handle, you will not be unloaded.
You did set a DriverUnload callback, right? A driver without that
callback cannot be unloaded.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you Tim.
Can I check for open handles in WinDBG? It’s possible there are open handles.
I don’t think we set DriverUnload function, but I think our other drivers don’t set this function also. If you “Disable” a driver that does not implement DriverUnload function, what is the expected behavior?
This is a driver for a detachable device. We register for Windows power event notifications and talk to our device as we need to.
xxxxx@gmail.com wrote:
Can I check for open handles in WinDBG? It’s possible there are open handles.
I don’t think we set DriverUnload function, but I think our other drivers don’t set this function also. If you “Disable” a driver that does not implement DriverUnload function, what is the expected behavior?
Well, for the record, I should state that what I’ve described is the
kernel-mode behavior. It would do exactly what you see. No new opens
would be allowed, but the driver would remain in memory. The next time
it was enabled, the system would start calling callbacks without going
through the load process, and of course without calling DriverEntry.
I’ve never tried this with a UMDF 2.0 driver. I tried looking in the
UMDF source, but I could not find the answer.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Device Manager is a good way to confirm your driver actually unloaded when you asked it to. If your drive leaves the list in Device Manager then it at attempted to unload. If you think its getting hung up because of open handles then you can find the WudfRd.sys instance that backs up your UMDF driver via ?!devnode 0 1?. Drilling into the devnode and seeing a current state like DeviceNodeRemovePendingCloses indicates handles are stuck.
For framework drivers like UMDF and KMDF you don?t have to set an unload routine. The framework manages that for you and allows you optionally register for it.