We keep on seeing this random error with one of our drivers and I was wondering if anyone else in the community has experienced the same.
It is a driver that supports unloading which occasionally during a product update is stopped using the Service Control manager (StopService), the file is replaced on disk with a new version and then restarted using StartService.
Once in a blue moon, the SCM returns ERROR_FILE_NOT_FOUND even though we have not played with its registration. All registry keys are in place AND a reboot is always solving this issue.
It is almost as SCM has now an invalid cache of the service with no path in it.
ProcMon shows services.exe reading the service registry key but no other values under it. (It tries to read ObjectName and cannot find it, but that is not the problem)
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@eeye.com
Sent: Thursday, October 28, 2010 7:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver fails to start with ERROR_FILE_NOT_FOUND
We keep on seeing this random error with one of our drivers and I was
wondering if anyone else in the community has experienced the same.
It is a driver that supports unloading which occasionally during a product
update is stopped using the Service Control manager (StopService), the file
is replaced on disk with a new version and then restarted using
StartService.
Once in a blue moon, the SCM returns ERROR_FILE_NOT_FOUND even though we
have not played with its registration. All registry keys are in place AND a
reboot is always solving this issue.
It is almost as SCM has now an invalid cache of the service with no path in
it.
ProcMon shows services.exe reading the service registry key but no other
values under it. (It tries to read ObjectName and cannot find it, but that
is not the problem)
Could you please make sure there isn’t a leaked reference to your driver somewhere ? This would exhibit the particular behavior you are seeing…
This is problematic to detect since after the driver is unloaded its DRIVER_OBJECT is no longer linked into the OB namespace so you can’t find it by name. Also, most of your other references are also gone (since you’re trying to unload presumably they’ve been cleaned up). The way i found i can investigate this issue is by logging the address of the DRIVER_OBJECT someplace and then do a !object on the address once the problem occurs.
That’s a possibility we need to investigate more. If I were to “fake” this leaked reference, what do you suggest I do?
Another possibility we thought of is that the stopping actually takes a long time and the restart of the driver happens before it completes. Incidentally we discovered that the code was not waiting on the driver to report a “stopped” status and maybe that throws SCM into confusion land. Will try to reproduce this also by having the Unload wait for a minute or so.