Hi,
I run FileMon (from Sysinternals), then close it. But I found that
even after closing FileMon, its driver (FileMon.Sys) is still kept in
the kernel.
A question: is there any way to unload the driver from kernel, without
having to restart my machine?
The reason I want to unload everything related to FileMon is that a
program packed with Themida refuses to run if FileMon is resident in
memory.
Thanks a lot,
Jun
No, no way to unload the driver. Once it gets its fingers into the system, it won’t let go
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jun Koi
Sent: Tuesday, March 16, 2010 9:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Unloading a driver from kernel?
Hi,
I run FileMon (from Sysinternals), then close it. But I found that even after closing FileMon, its driver (FileMon.Sys) is still kept in the kernel.
A question: is there any way to unload the driver from kernel, without having to restart my machine?
The reason I want to unload everything related to FileMon is that a program packed with Themida refuses to run if FileMon is resident in memory.
Thanks a lot,
Jun
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
Is there any specific reason for this? In linux, a kernel module can be
unloaded by “rmmod”!
No, no way to unload the driver. Once it gets its fingers into the
system, it won’t let god
Scanned and protected by Email scanner
I didn’t say that any driver cannot be unloaded. FileMon itself cannot be unload b/c of the way it gathers information. There is no clean way to unload it once it is in place.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lloyd
Sent: Tuesday, March 16, 2010 11:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Unloading a driver from kernel?
Is there any specific reason for this? In linux, a kernel module can be unloaded by “rmmod”!
No, no way to unload the driver. Once it gets its fingers into the
system, it won’t let god
Scanned and protected by Email scanner
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
On Wed, Mar 17, 2010 at 3:10 PM, Doron Holan wrote:
> I didn’t say that any driver cannot be unloaded. ?FileMon itself cannot be unload b/c of the way it gathers information. There is no clean way to unload it once it is in place.
OK, suppose that it is possible to unload a driver cleanly, then which
tool/solution should be used?
Thanks,
Jun
FileMon.Sys can not be unloaded.There is no unload function in it.
#if DBG
//
// Driver unload is only set if we are debugging Filemon. This is
// because unloading a filter is not really safe - threads could
// be in our fastio routines (or about to enter them), for example,
// and there is no way to tell. When debugging, we can risk the
// occasional unload crash as a trade-off for not having to
// reboot as often.
//
// DriverObject->DriverUnload = FilemonUnload;
#endif // DBG
For a legacy driver (like filemon)
net stop
from an elevated command prompt will attempt an unload. The driver has to have an unload routine and all handles have to be closed for the driver to be unloaded. For a pnp driver, you must stop every stack that the driver is running on.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jun Koi
Sent: Tuesday, March 16, 2010 11:24 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Unloading a driver from kernel?
On Wed, Mar 17, 2010 at 3:10 PM, Doron Holan wrote:
> I didn’t say that any driver cannot be unloaded. ?FileMon itself cannot be unload b/c of the way it gathers information. There is no clean way to unload it once it is in place.
OK, suppose that it is possible to unload a driver cleanly, then which
tool/solution should be used?
Thanks,
Jun
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
> Is there any specific reason for this? In linux, a kernel module can be
unloaded by “rmmod”!
So happens in Linux if other kernel modules were loaded later that attached
to exported functions of that module?
Jan
“So what happens in Linux if other kernel modules were loaded later that
attached to exported functions of that module?”
Well, if you believe the Apple vs PC ads, a little bitty faerie pops up
amidst a poof of pixie … oops … faerie dust and magically relinks all
those orhaned links such that of course Linus’s precious LINUX will not fall
on it’s frigging face. In reality what happens is … it falls on it’s
frigging face.
The personal opinion of
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, March 17, 2010 12:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Unloading a driver from kernel?
Is there any specific reason for this? In linux, a kernel module can be
unloaded by “rmmod”!
So happens in Linux if other kernel modules were loaded later that attached
to exported functions of that module?
Jan
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
__________ Information from ESET Smart Security, version of virus signature
database 4951 (20100317) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature
database 4951 (20100317) __________
The message was checked by ESET Smart Security.
Choose the soup dejour of your choice.
Open a command line window and enter “net stop ”.
Open DevMgmt.msc, go to your driver and Disable/Uninstall it.
Open a powershell window and use “stop_service drivername”.
Except for Vista — I’ve found no iteration that will work in
Vista’s powershell installations.
Open regedit, go tip-toeing through the registry and manually delete every
frigging entry you find with the driver name in it, then search for and
delete EVERY INSTANCE of the sys and inf file from the disk.
Mostly it is your choice on what you use, though of them all, Uninstall in
DevMgmt is the most likley to NOT bluescreen, and will even remove a driver
that has no Unload routine. Of course, if it is in Windows file protection
schema, those faeries that keep Linux from failing will magically appear in
a poof of faerie dust and re-install it.
The personal opinion of
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jun Koi
Sent: Tuesday, March 16, 2010 11:24 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Unloading a driver from kernel?
On Wed, Mar 17, 2010 at 3:10 PM, Doron Holan
wrote:
> I didn’t say that any driver cannot be unloaded. ?FileMon itself cannot be
unload b/c of the way it gathers information. There is no clean way to
unload it once it is in place.
OK, suppose that it is possible to unload a driver cleanly, then which
tool/solution should be used?
Thanks,
Jun
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
Information from ESET Smart Security, version of virus signature
database 4951 (20100317)
The message was checked by ESET Smart Security.
http://www.eset.com
Information from ESET Smart Security, version of virus signature
database 4951 (20100317)
The message was checked by ESET Smart Security.
http://www.eset.com
>
“So what happens in Linux if other kernel modules were loaded later
that
attached to exported functions of that module?”Well, if you believe the Apple vs PC ads, a little bitty faerie pops
up
amidst a poof of pixie … oops … faerie dust and magically relinks
all
those orhaned links such that of course Linus’s precious LINUX will
not fall
on it’s frigging face. In reality what happens is … it falls on it’s
frigging face.
Only if the driver has bugs in it. For most of the driver development
work I’ve done under Linux it’s just a matter of:
insmod
test things. Make changes. Recompile.
rmmod
rinse. repeat.
James
James Harper wrote:
Only if the driver has bugs in it. For most of the driver development
work I’ve done under Linux it’s just a matter of:insmod
> test things. Make changes. Recompile.
> rmmod
> rinse. repeat.
>
But the driver in your example isn’t part of any stack – it doesn’t
have any drivers that are loaded on top of it. If it did, you’d be in
exactly the same situation.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>
James Harper wrote:
> Only if the driver has bugs in it. For most of the driver
development
> work I’ve done under Linux it’s just a matter of:
>
> insmod
> > test things. Make changes. Recompile.
> > rmmod
> > rinse. repeat.
> >
>
> But the driver in your example isn’t part of any stack – it doesn’t
> have any drivers that are loaded on top of it. If it did, you’d be in
> exactly the same situation.
>
I’ve worked on ISDN drivers and SCSI drivers under Linux, both of which
have multiple drivers loaded on top of and under them (eg tape drives
etc). If a user process has the underlying device open then of course
you can’t unload it, but it certainly doesn’t fall flat on its face, it
just tells you that it can’t unload right now, and so you stop the user
process and try again.
James
On Wed, 2010-03-17 at 16:08 -0700, Tim Roberts wrote:
James Harper wrote:
> Only if the driver has bugs in it. For most of the driver development
> work I’ve done under Linux it’s just a matter of:
>
> insmod
> > test things. Make changes. Recompile.
> > rmmod
> > rinse. repeat.
> >
>
> But the driver in your example isn’t part of any stack – it doesn’t
> have any drivers that are loaded on top of it. If it did, you’d be in
> exactly the same situation.
>
Doesn’t matter. Linux works by maintaining a reference count against
the module. When a module is inserted that references a prior module’s
API, the count on the prior module is increased, and an rmmod on that
module will fail.
Here, for example is a partial list of some of the modules inserted in
this machine (my machine currently has 113 modules inserted):
bridge 75144 1
stp 3340 1 bridge
In this case, module ‘stp’ is referencing something in ‘bridge’. (and
in fact, somebody else is referencing stp)
Should I try to remove the stp module:
hermosa:~ # rmmod stp
ERROR: Module stp is in use by bridge
and all is well.
Usually the case, during development, is that you screw up the ref count
positively, such that you cannot remove your module during development
(thus requiring a reboot).
Module insertion is also smart enough to deal with changes to APIs so
that should an API incompatible change occur between the kernel and the
module, the module cannot be inserted.
Best,
-PWM
Peter W. Morreale wrote:
On Wed, 2010-03-17 at 16:08 -0700, Tim Roberts wrote:
> James Harper wrote:
>
>> Only if the driver has bugs in it. For most of the driver development
>> work I’ve done under Linux it’s just a matter of:
>>
>> insmod
>>> test things. Make changes. Recompile.
>>> rmmod
>>> rinse. repeat.
>>>
>>>
>> But the driver in your example isn’t part of any stack – it doesn’t
>> have any drivers that are loaded on top of it. If it did, you’d be in
>> exactly the same situation.
>>
>
> Doesn’t matter. Linux works by maintaining a reference count against
> the module. When a module is inserted that references a prior module’s
> API, the count on the prior module is increased, and an rmmod on that
> module will fail.
>
Yes. I wasn’t going to pursue this thread any further, but the point I
was trying to make was merely that a Linux driver and a Windows driver
have exactly the same limitations in this regard, and mostly the same
behavior. I was not trying to bolster the original hysterical argument
that unloading a Linux driver causes disaster, and I should have made
that clear.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Wed, 2010-03-17 at 17:17 -0700, Tim Roberts wrote:
…
… I was not trying to bolster the original hysterical argument
that unloading a Linux driver causes disaster, and I should have made
that clear.
nod. Some people’s children seem prone to hysteria.
Best,
-PWM
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Yes. I wasn’t going to pursue this thread any further, but the point I
> was trying to make was merely that a Linux driver and a Windows driver
> have exactly the same limitations in this regard, and mostly the same
> behavior. I was not trying to bolster the original hysterical argument
> that unloading a Linux driver causes disaster, and I should have made
> that clear.
To make it clearer maybe it woud be worth to say that reference counts
by themselves are not enough for dynamic unloading.
There should be a way to track entities that reference the driver in
question, and ask them to go away.
Example: safely remove a USB disk. All layers above the disk are notified
and properly wrap in (and sometimes they fail to do so because something
else still sits on top of them).
In the case of legacy FS filters like Filemon, there is no way to notify
upper layers.
This is why they are usually not removable.
OTOH, FS minifilters provide such way, so they may be removable.
Hope this helps…
– pa