Re: Fltmc Load driver failed. (ERROR_FILE_NOT_FOUND)

NTFSD
1

I would agree that is most likely the case. We have run into a similar
situation where only after a reboot can you install and load the same
driver again. I believe what happens is that if the driver cannot be
cleanly unloaded during uninstall, then Windows will mark the driver
as to be deleted and will clean it up during reboot. So even if you
try to install again, the driver is still marked as to be deleted and
you cannot load it.

One quick way to test this is to do a sc delete on the service
associated with the driver after the uninstall and see if the driver
is reported as marked for deletion.

Hao

On Mon, May 21, 2012 at 12:33 PM, wrote:
> The behavior you’ve described makes me suspect that the unload isn’t actually completing.
>
> I’m not sure where the ERROR_FILE_NOT_FOUND is coming from but I’d suggest walking through the process in the debugger, it’s pretty straightforward and in my experience it’s not hard to figure out what was actually not found.
>
> Thanks,
> Alex.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

2

I am throwing pure guess here now, but in the past I noticed that ERROR_FILE_NOT_FOUND can also be returned when the registry key was not found (not just the file name). So yes, you are trying to load a driver that has been unloaded before, perhaps check the registry key under “Services”.

Let me know if that helped.

3

Well, the OP mentioned the key was fine so I didn’t think this was the case… However, for the record, I’ve investigated a case where the default instance key was missing and the minifilter failed to load with STATUS_OBJECT_NAME_NOT_FOUND.

Thanks,
Alex.

4

Thanks for all your answers.

I want to clear a few things:

  1. The registry keys are good, the default instance is there. But the enum folder not there, but this folder will be created after the first time to load the driver.
  2. The driver is not marked as deleted, use sc delete mydriver, it return succeeded.
  3. If i rename my driver name “mydriver.sys” to “mydriver.new.sys”, and at the same time i change the key “ImagePath” point to the path “mydriver.new.sys”, it is fine to load the driver.
  4. If i don’t anything, just reboot the driver, it will be fine after it was booted.

Alex, I want to know how to debug it with Windbg if this happened ? I used process monitor, i didn’t see something suspicious.

Thanks
Ts

5

You would need to attach a kernel debugger (Windbg) and start tracing through the FltXxx api that’s failing. I don’t know of another way. ProcMon isn’t generally useful for this sort of thing.

What do you do in your unload routine ?

Thanks,
Alex.

6

> I would agree that is most likely the case. We have run into a similar

situation where only after a reboot can you install and load the same
driver again. I believe what happens is that if the driver cannot be
cleanly unloaded during uninstall, then Windows will mark the driver
as to be deleted and will clean it up during reboot. So even if you
try to install again, the driver is still marked as to be deleted and
you cannot load it.

****
Yes, if the unload fails, the system is left in an inconsistent state,
where parts of it think the driver is unloaded and other parts think it is
still running. It has nothing to do with the files being entered in the
deferred-deletion list. You could see the same problem in NT 3.x. I
rarely “uninstall” a driver during development, I just use windbg’s
ability to rediect the .sys file to get the latest copy from my devlopment
machine.

Suck it up. A reboot is required. A driver which cannot be unloaded is
defective, and the system does not guarantee sane behavior when kernel
components are defective.

That said, one of the great motivators for writing robust drivers is so
you can unload them and load a new one without rebooting. This means you
properly handle cancellation requests, complete a pending IRP when there
is a failure, etc. One classic failure pattern I look for, and find a
frighteningly large number of times is

ASSERT(p != NULL);
if(p == NULL)
return STATUS_SOMETHING_NOT_SUCCESS;
…do stuff
IoCompleteRequest(irp, …);

do you see where the IRP was completed if the pointer was NULL? Right!
This is a fragile, defective driver.

You still end up doing a lot of reboots, but writing robust code reduces
these to a tolerable level.
joe
*****

One quick way to test this is to do a sc delete on the service
associated with the driver after the uninstall and see if the driver
is reported as marked for deletion.

Hao

On Mon, May 21, 2012 at 12:33 PM, wrote:
>> The behavior you’ve described makes me suspect that the unload isn’t
>> actually completing.
>>
>> I’m not sure where the ERROR_FILE_NOT_FOUND is coming from but I’d
>> suggest walking through the process in the debugger, it’s pretty
>> straightforward and in my experience it’s not hard to figure out what
>> was actually not found.
>>
>> Thanks,
>> Alex.
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

7

Just as a note (since this is a file systems group) there are reasons that file system drivers are not always unloadable. The FAT file system example has an Unload routine, but a fairly quick review of the code will clearly show you that it is not safely unloadable. Nor is NTFS. I wouldn’t suggest either of them is broken.

Tony
OSR