Re: Self-removing driver
- From: Brett <elderdodds@xxxxxxxxxxxx>
- Date: Wed, 15 Jul 2009 15:48:01 -0700
Thank you everybody for some great replies.
I ended up following Volodymyr M. Shcherbyna's suggestion:
1) Added a global variable called HandleCount (yes, I know globals are
usually evil) and initialized it to 0.
2) Incremented HandleCount on IRP_MJ_CREATE
3) Decremented HandleCount on IRP_MJ_CLOSE
4) In IRP_MJ_CLOSE, I checked for HandleValue == 0 and fired the named event
(created in user mode application).
I also added:
if(HandleCount > 0)
return;
to my Unload routine to prevent a closing conflict as suggested by Pavel A.
It is working perfectly now.
Again, thanks!
-Brett
"Don Burn" wrote:
Another approach to this is to write seperate wrapper drivers for a common.
kernel mode DLL and have each app have its own wrapper. The DLL containing
the bulk of the code gets unloaded when the last driver is unloaded, the
wrappers can be a DriverEntry and Unload, all the major functions can
reference the DLL.
--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Pavel A." <pavel_a@xxxxxxxxxxxxxxx> wrote in message
news:uB9H1sTBKHA.1488@xxxxxxxxxxxxxxxxxxxxxxx
Volodymyr Shcherbyna wrote:
"Tim Roberts" <timr@xxxxxxxxx> wrote in message
news:d7tq555emj4bfofhgottqqk3hsu384fjf3@xxxxxxxxxx
[...]
Is there really any reason to stop and delete the service when you're
done?
If this is something you might use in several different tools, why not
just
leave it running?
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Or to put driver into idle state untill machine reboots. The case with
dynamic uninstallation has a problem, as when the application think
driver is done, it tries to uninstall it, and another application is
opening the handle on driver. IMO, better solution is to put driver into
idle mode via ioctl, and uninstall it using SCM api, the driver would not
unload untill machine reboots, but at least this design is safe and
simple.
+1.
Combined with reference counting in the driver itself, to prevent
unload while in use.
Since this is a legacy driver, zero the
unload handler pointer to prevent unload, and set it when
the open count becomes 0, to allow unloading.
If the driver startup type is demand, there's really no need to
remove it, you can leave it installed.
-- pa
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4245 (20090715) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4245 (20090715) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
- Follow-Ups:
- Re: Self-removing driver
- From: Volodymyr M. Shcherbyna
- Re: Self-removing driver
- References:
- Self-removing driver
- From: Brett
- Re: Self-removing driver
- From: Tim Roberts
- Re: Self-removing driver
- From: Volodymyr Shcherbyna
- Re: Self-removing driver
- From: Pavel A.
- Re: Self-removing driver
- From: Don Burn
- Self-removing driver
- Prev by Date: Re: Mouse filter Add-on
- Next by Date: RE: Hello~!! I want to debug driver loaded on windws system.
- Previous by thread: Re: Self-removing driver
- Next by thread: Re: Self-removing driver
- Index(es):
Relevant Pages
|
Loading
