KMDF can't unload if the driver is opened by CreateFile in user mode

Hi I have a KMDF driver and I setup EvtCleanupCallback. so if the driver not opened in user mode everything is fine it load/unload automation but if I use CreateFile open it without close it. Then it can’t be unload any more even the usb is plugoff control device is delete but the driver sting running. Does anyone meet this issue before? How to fix it? Thanks.

Perhaps the first step toward fixing it would be to post your question to the correct forum.

Moving this to NTDEV.

Peter

1 Like

Does your Cleanup callback get called? You probably want to use EvtFileClose, not Cleanup… by the way.

Does the app have Requests in progress when the handle is closed? Do you cancel these Requests?

Peter

2 Likes

Hi Peter, Thanks for your reply. Yes the Cleanup called by system. I will have a try about EvtFileClose. So I think I should handle both Cleanup and EvtFileClose right. So if no app open the driver it can be delete by system in Cleanup callback. or when the app close the handle I can delete in EvtFileClose right?

Not QUITE right, no.

I previously wrote this, which you did not answer:

Does the app have Requests in progress when the handle is closed? Do you cancel these Requests?

So, you might start by answering those questions, please.

I would guess that the app doesn’t JUST have the device open, but actually has one or more read/write/IOCTL requests active on the device (waiting to be serviced by your driver). If this is the case, you need to handle them via CANCEL… not Cleanup or Close. See this topic for some discussion about cancel (I admit this documentation is confusing).

You should not need to use either Cleanup or Close… Many people misunderstand Cancel and think they should handle this operation via Cleanup. But that is not correct.

Peter

I have not met the problem with file but socket. My kernel mode driver could not unload if I don’t close the opened socket.
I guess this case is same.

Hi Peter_Viscarola_(OSR) sorry for the delay reply. For the question I am not sure if any APP sand request when the driver is unload. But I am not handle the cancel request. will try it. right now the use case is: CreateFile=>send IOCTL=>plugoff=>CloseFile=>driver still running and it can’t be uninstall except reboot the machine. I think the driver should be unload when the device plugoff at the 3rd step even the app still hold the handle of control driver.

I think the driver should be unload when the device plugoff at the 3rd step

I agree. The problem you’re almost certainly having is that the IOCTL is still in progress (during the unplug). You need to cancel that IOCTL. That’s what Request Cancellation is for.

Good luck!

Peter

Hi Peter. I tried that remove all request. Just do step CreateFile(mydriver)=>plugoff device=>CloseFile=>mydriver still running. So seem the issue is not because of the request. My driver is a usb filter driver. when I do step CreateFile(mydriver)=>CloseFile=>plugoff device=>mydriver stopped as expect. So seems the handle block the system unload the driver. So how to let the driver unload even it is opened by an application?

should I need set the pnp capabilities for the filterdevice?

WDF_DEVICE_PNP_CAPABILITIES_INIT(&pnpCaps);

pnpCaps.Removable         = WdfTrue;
pnpCaps.SurpriseRemovalOK = WdfTrue;
pnpCaps.NoDisplayInUI     = WdfTrue;

pnpCaps.Address  = InstanceNo;
pnpCaps.UINumber = InstanceNo;

WdfDeviceSetPnpCapabilities(FilterDevice, &pnpCaps);

Your driver cannot unload while an application has an open file handle. However, when your application closes the handle, then your driver will unload. If you’re using KMDF queues, then the framework should be canceling any open requests when you get surprise removed. The application has to be smart enough to close the handle when that happens.

Hi Tim. Thanks for your confirmation. another question what should I setting the “StartType” for a kmdf pnp driver in inf file. right now I use 3 SERVICE_DEMAND_START. it work well but if customer use command “sc start” to start the driver it will cause application failed to connect with it by CreateFile. And it will let the driver can not be uninstalled. So is there a way to disable the customer to use command “sc start” to start the driver?

If you have are a PnP device, then SERVICE_DEMAND_START is what you want. If someone stupidly does “sc start” on your driver, your DriverEntry will run, but your DriverEntry doesn’t do anything. A PnP driver does not create any devices until AddDevice, which won’t get called. Thus, as soon as DriverEntry returns, your driver will be unloaded. No harm done.

But after start with command “sc start”. the driver not unloaded. it running and can’t stop or uninstall until I plugin and plugoff a usb. after plugin and plugoff a usb the driver stopped. I guess the stop only happens until EvtCleanupCallback called. but it only called when a device plugoff.

Yep. So, don’t do that. A user who tries to “sc start” a PnP driver is an idiot. You can’t protect against idiots. They’re too clever.

1 Like