A case has come up where a WinXP SP2 kernel mode driver gets loaded, but its DriverEntry never gets called. It eventually gets unloaded. Anyone care to explain why? By the way the same driver on a different PC - the driver loads, DriverEntry gets called, life is good. Registry entries for this driver are identical on both machines. The driver is registered as a “filter” driver. Its’ load time is system boot - and it does get loaded then, on both machines. Within a split second after continuing from the inital system boot break point, the DriverEntry is called on the “good” PC. No other drivers are loaded between the initial boot break point and the DriverEntry call - exactly what I would expect to happen. On the “bad” PC, the driver is loaded. It’s symbols are also loaded. I can set break points in the code, etc. I let the system continue from the initial boot break point and after waiting a while, I break again and check the modlue list and the driver has been unloaded. By the way - the class driver that this driver filters hasn’t even been loaded yet, but the driver already gets unloaded. I’ve worked writing NT kernel drivers for over 10 years, worked onsite at Microsoft for over a year with other kenerl driver writers while Win2K and WinXP were being developed, and I cannot explain this. The driver in question is a mature driver that has shipped on tens of thousands of PCs. This is a case of one PC fails - every other PC tested with succeeds - DriverEntry gets called. Any ideas?
xxxxx@yahoo.com wrote:
A case has come up where a WinXP SP2 kernel mode driver gets loaded, but its DriverEntry never gets called. It eventually gets unloaded. Anyone care to explain why? … The driver in question is a mature driver that has shipped on tens of thousands of PCs. This is a case of one PC fails - every other PC tested with succeeds - DriverEntry gets called. Any ideas?
How do you know that DriverEntry is not called? Is it just a missing
debug message, or is there actually state that doesn’t get set? I’ve
seen some systems where early boot debug messages get lost.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes - there is state that does not get set. I went to great lengths when this issue on this one machine first showed up to ensure that even if the driver gets unloaded, but had its driver entry called, it would leave a memory signature that would could be found regardless of what else happened in the kernel. It simply does not get called. I’m considering walking the driver loader call stack and trying to determine what criteria is being used for this decision. It won’t be easy since I don’t have source. Any other ideas?
Never mind - I found the problem - the devices that the driver is supposed to filter had been
explicitly disabled by the user. So in this case the driver gets loaded, but shortly before its
DriverEntry function gets called, the OS determines that the devices it has previously worked
with are all explicitly disabled and so it doesn’t call the DriverEntry and unloads the driver.
I think there is something wrong with this scenario - perhaps there will be an additional, new
device that does need to be filtered by this driver. But the driver won’t have been loaded at
boot time and won’t have set up its boot time stuff. It will get loaded later, when the system
realizes there is a new device, but by then some of the stuff it was supposed to do it cannot
do. Hmmm…
This is different behavior than if the devices simply had been removed from the system (not
disabled by the control panel, but actually removed/turned off, etc.). In this case where the
devices were removed, the driver still loads and its DriverEntry gets called. And every boot
afterwards as well, even though the OS “knows” after that first boot without the devices that
there aren’t any devices for it to work with.
By saying “knows” I mean it in the same sense that the OS “knows” that it shouldn’t load the
driver just because the previous devices it had worked with are disabled and therefore there is
no reason to load the driver (even though there might be a new device 
)
Something doesn’t seem quite right about this - I can understand why MS may have done this.
It would allow someone to disable a device and keep its drivers from loading and therefore work
around some kind of system problem or even BSOD. But it does present a problem in that the
next time a new device happens to be added, the driver won’t be loaded at boot time. The
worst that can happen from this is that an extra reboot is needed, so it hurts PnP a little. But that
is about all.
Greg