Hello,
I found some strange behaviour, and I want to ask about your experience
on that.
Currently, I'm working on a driver which is not WDM, but legacy NT4. It
is installed and uninstalled via the service control manager (SCM).
As the driver verifier does some tests when a driver is unloaded, I have
the following procedure in a test application for now:
1. Start the driver (equivalent to "net start <drivername>")
2. Open the device and do what I want
3. ...
4. Close the device
5. Stop the driver (equivalent to "net stop <drivername>")
No. 1 and 5 will not be available in the resulting version of the
driver, but they are there for now.
Now, everything works for now, even the driver verifier does not
complain. One of the persons I send the driver for additional testing
did the following on his machine: He starts several instances (6, to be
precise) of this test application above, to make sure that this case is
handled correctly. Here, the "..." above (no. 3) is especially short,
thus, the driver does not perform any work at all, but quits rather
quickly.
On my machine (uniprocessor), everything works fine, no problems at all.
To my surprise, on his machine (hyper-threading) as well as on another
machine (SMP), the system bugchecks. Most often, it bugchecks with a
DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS, sometimes, there
is a IRQL_NOT_LESS_OR_EQUAL.
Unfortunately, I do not have a HT or an SMP machine here. Anyway, from
the kernel dumps both send me, I found out that the driver was just
executing something in the DriverEntry() routine. Every time, it
bugchecks at different places, but it is always in the DriverEntry(), or
in functions which are only called from there.
If no. 1 and 5 above (starting and stopping the driver) is omitted,
everything works perfectly.
So, to me, it seems that No 5 (stopping the driver) in one instance of
the test application, and no 1 (starting the driver) in another instance
can occur simultaneously in the system on HT or SMP machines. Is this
true? Is there anything I can do about it to prevent this?
From my understanding, starting a driver via SCM will return with an
error message if the driver is already loaded. Thus, if stopping has not
yet taken place, another instance of the test app cannot start the
driver, thus, the driver would never reach the DriverEntry() routine.
But, from the crash dump, it must have reached the DriverEntry()
routine.
If the bugcheck would occur while operating the driver (no. 2-4), I
would think it is a design flaw of mine. But this does not happen!
Currently, to me, it seems like a design flaw of the OS, but I hope that
I'm mistaken here. ;-)
Any hints, suggestions, and remarks are welcome!
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/