Software only driver can be unloaded even though application has open handles

Hi All,

I am experimenting MS sample file system mini filter driver. I have a question regarding the driver unload scenario.
I have created a handle in my application to the device object created in the driver. Even though my application is running and opened a handle,
I was able to unload the driver using “sc stop servicename.sys” from the admin command prompt.

I was thinking that, if any open handle is present the system will not unload the driver. But it seems wrong.
Could anyone please clarify what is happening in this case. Why driver unloaded even though handle is opened at the application?

Thanks,
Parsa

software only or legacy // NT4 style drivers can be unloaded with open handles. DriverUnload will run but the image will stay loaded until the last open handle is closed. This means you have be careful about the state you tear down in DriverUnload and the code outside of DriverUnload that may rely on it. It also makes image unload tricky as now the image may be unloaded as soon as your IRP_MJ_CLOSE returns back to the IO manager so you need to also make sure any outstanding timers/DPCs/etc are run down before returning.

1 Like

Hmm … so to be clear, if I have a KMDF driver that is loaded with a “ROOT\Blargh” interface I may still have open file handles even after DriverUnload and Driver::ContextCleanup? How about after Device::RemoveHardware and Device::ContextCleanup?

Thanks, Doron.

> @craig_howard said: > Hmm … so to be clear, if I have a KMDF driver that is loaded with a “ROOT\Blargh” interface I may still have open file handles even after DriverUnload and Driver::ContextCleanup? How about after Device::RemoveHardware and Device::ContextCleanup? You are describing a software only pnp device driver. The behavior is described is for a legacy pre pnp driver (in this case a fs filter) Parsa, I know very little about FS filter drivers, but I think if you want to experiment with FS filters, you want to start with a filter manager based driver.

@Doron_Holan Ah, good (whew!) … wanted to be crystal clear that all of my software drivers aren’t going to be exploding like little popcorn kernels … :slight_smile:

Yet another good reason why KMDF is the way to go …

@Doron_Holan I am using filter manager in my fs filter driver. It provides communication port to interact with the user mode. I just want to have some sideband communication using the device object in my app.

@Doron_Holan I have one more doubt. When the driver has created a device object and it is not deleting that device object, in this case also software only legacy driver can be unloaded without any issue.

You seem to be mixing up PnP and non-PnP devices in your scenario. I’m not sure why a non-PnP driver would ever create a child device object. You can’t get a driver loaded for it unless it is PnP, in which case the parent needs to be PnP as well.

Hi Tim,

https://github.com/microsoft/Windows-driver-samples/blob/master/filesys/miniFilter/cdo/CdoInit.c

I am referring to the above code where it creates control device object for user mode communication. And the device object is getting deleted in the DriverUnload routine. Just wondering what will happen if device object is not deleted explicitly during the driver unload. Will OS identify that the device object is getting leaking and don’t unload the driver.

As i described already, the outstanding Ob reference from the file handle will keep the image loaded after DriverUnload has returned. As a reference point, the Kmdf runtime is loaded as a nt4 style legacy driver by wdfldr and has to account for an external unload event (sc stop …) and keep the runtime loaded after the unload. It does this by keeping an open file handle on the Kmdf runtime and closes it when the last Kmdf client driver unloads (which in a modern system never happens as there are Kmdf client drivers who can’t unload).

1 Like