Hello Everybody,
I was wondering if it is possible to install/update a PnP filter driver of class DiskDrive without rebooting the machine? Any suggestion or work around this problem is appreciated.
Thanks,
Hossein
xxxxx@datagardens.com wrote:
I was wondering if it is possible to install/update a PnP filter driver of class DiskDrive without rebooting the machine? Any suggestion or work around this problem is appreciated.
A PnP filter is only loaded when a device is starting up. So, you can
install your filter, but it won’t take effect until the disk drive is
disabled and re-enabled, and you can’t do that to the system drives
without rebooting.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes. The device stacks will be restarted by your installer such as difx. But your boot disk will not load the filter until reboot.
-------- Original message --------
From: Tim Roberts
Date:04/02/2014 11:55 (GMT-08:00)
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Install/Update a DiskDrive filter driver without reboot
xxxxx@datagardens.com wrote:
I was wondering if it is possible to install/update a PnP filter driver of class DiskDrive without rebooting the machine? Any suggestion or work around this problem is appreciated.
A PnP filter is only loaded when a device is starting up. So, you can
install your filter, but it won’t take effect until the disk drive is
disabled and re-enabled, and you can’t do that to the system drives
without rebooting.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
No.
wrote in message news:xxxxx@ntdev…
> Hello Everybody,
>
> I was wondering if it is possible to install/update a PnP filter driver of class DiskDrive without rebooting the machine? Any suggestion or work around this problem is appreciated.
>
> Thanks,
> Hossein
>
If it is the boot drive then no. For other drives yes, you can dynamically load and unload your filter with no system restarts. In fact DIFx will automatically cycle the disk drives for you so that dynamic load & unload occurs seamlessly.
It also depends on how you are filtering. A conforming filter that attaches via AddDevice and creates a device object will be ok. A filter that performs dispatch hooks or such probably won’t be able to unload.
Mine is a driver of class DiskDrive, PnP upper-filter, and yes it attaches to all disk drives including the boot drive. In fact, I filter every and all writes to all disks at block level.
Can I get the same functionality with another class of drivers? Most probably no, but any thought or work around solution would be appreciated.
xxxxx@datagardens.com wrote:
Mine is a driver of class DiskDrive, PnP upper-filter, and yes it attaches to all disk drives including the boot drive. In fact, I filter every and all writes to all disks at block level.
Can I get the same functionality with another class of drivers? Most probably no, but any thought or work around solution would be appreciated.
There is no way to insert a filter driver into a stack that is already
built.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“There is no way to insert a filter driver into a stack that is already
built.”
True, but this sounds like you need to reboot, when in reality, you CAN
restart the devices without a reboot, with the exception of the boot disk
and paging disk. The installer can handle this for you using something like
difx.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 3, 2014 10:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Install/Update a DiskDrive filter driver without reboot
xxxxx@datagardens.com wrote:
Mine is a driver of class DiskDrive, PnP upper-filter, and yes it attaches
to all disk drives including the boot drive. In fact, I filter every and all
writes to all disks at block level.
Can I get the same functionality with another class of drivers? Most
probably no, but any thought or work around solution would be appreciated.
There is no way to insert a filter driver into a stack that is already
built.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
> In fact, I filter every and all writes to all disks at block level.
This won’t necessarily be true in all cases. You won’t get writes from after market drivers that bypass the stack and send the writes to the PDO. Hence, filter drivers in the storage area often require a different type of filter attachment such as dispatch hooks. But here again there is now another issue in hyper-v that was discussed in another thread that one of the Microsoft filter drivers handles disk i/o directly so lower filters don’t see even normal file system requests.
For update: what about splitting your driver into 2 components ? The first one will be just a place holder in the stack but all the core logic is in 2nd one that you can dynamically load/unload. At load time 2nd one can provide its function pointers to the first one [e.g. using an IOCTL]. The first one will also need some logic to pause/resume Irps momentarily when the load/unload process happens.
Just a thought.
SUlSQywgYW55L2FsbCBzeXN0ZW0gZGlza3MgY2Fubm90IGJlIHJlc3RhcnRlZC4gU28gYm9vdCBh
bmQgcGFnZWZpbGUgZGlza3MuwqAKCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t
LS0tLTwvZGl2PjxkaXY+RnJvbTogTWFyaW9uIEJvbmQgPGJvbmRtYXJpb25AaG90bWFpbC5jb20+
IDwvZGl2PjxkaXY+RGF0ZTowNC8wMy8yMDE0ICAxNjozMiAgKEdNVC0wODowMCkgPC9kaXY+PGRp
dj5UbzogV2luZG93cyBTeXN0ZW0gU29mdHdhcmUgRGV2cyBJbnRlcmVzdCBMaXN0IDxudGRldkBs
aXN0cy5vc3IuY29tPiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFtudGRldl0gUmU6IFtudGRldl0gSW5z
dGFsbC9VcGRhdGUgYSBEaXNrRHJpdmUgZmlsdGVyIGRyaXZlciB3aXRob3V0IHJlYm9vdCA8L2Rp
dj48ZGl2Pgo8L2Rpdj5JcyBpdCB0aGUgYm9vdCBkaXNrIG9yIGp1c3QgYW55IHRoYXQgaGF2ZSBw
YWdlIGZpbGVzPyAKClNlbnQgZnJvbSBTdXJmYWNlIFBybwoKRnJvbTogS2VubnkgU3BlZXIKU2Vu
dDog4oCOV2VkbmVzZGF54oCOLCDigI5BcHJpbOKAjiDigI4wMuKAjiwg4oCOMjAxNCDigI4z4oCO
OuKAjjEw4oCOIOKAjlBNClRvOiBXaW5kb3dzIFN5c3RlbSBTb2Z0d2FyZSBEZXZzIEludGVyZXN0
IExpc3QKClllcy4gVGhlIGRldmljZSBzdGFja3Mgd2lsbCBiZSByZXN0YXJ0ZWQgYnkgeW91ciBp
bnN0YWxsZXIgc3VjaCBhcyBkaWZ4LiBCdXQgeW91ciBib290IGRpc2sgd2lsbCBub3QgbG9hZCB0
aGUgZmlsdGVyIHVudGlsIHJlYm9vdC4gCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t
LS0tCkZyb206IFRpbSBSb2JlcnRzCkRhdGU6MDQvMDIvMjAxNCAxMTo1NSAoR01ULTA4OjAwKQpU
bzogV2luZG93cyBTeXN0ZW0gU29mdHdhcmUgRGV2cyBJbnRlcmVzdCBMaXN0ICAKU3ViamVjdDog
UmU6IFtudGRldl0gSW5zdGFsbC9VcGRhdGUgYSBEaXNrRHJpdmUgZmlsdGVyIGRyaXZlciB3aXRo
b3V0IHJlYm9vdAoKaGF6YXJpQGRhdGFnYXJkZW5zLmNvbSB3cm90ZToKPiBJIHdhcyB3b25kZXJp
bmcgaWYgaXQgaXMgcG9zc2libGUgdG8gaW5zdGFsbC91cGRhdGUgYSBQblAgZmlsdGVyIGRyaXZl
ciBvZiBjbGFzcyBEaXNrRHJpdmUgd2l0aG91dCByZWJvb3RpbmcgdGhlIG1hY2hpbmU/IEFueSBz
dWdnZXN0aW9uIG9yIHdvcmsgYXJvdW5kIHRoaXMgcHJvYmxlbSBpcyBhcHByZWNpYXRlZC4KCkEg
UG5QIGZpbHRlciBpcyBvbmx5IGxvYWRlZCB3aGVuIGEgZGV2aWNlIGlzIHN0YXJ0aW5nIHVwLiAg
U28sIHlvdSBjYW4KaW5zdGFsbCB5b3VyIGZpbHRlciwgYnV0IGl0IHdvbid0IHRha2UgZWZmZWN0
IHVudGlsIHRoZSBkaXNrIGRyaXZlIGlzCmRpc2FibGVkIGFuZCByZS1lbmFibGVkLCBhbmQgeW91
IGNhbid0IGRvIHRoYXQgdG8gdGhlIHN5c3RlbSBkcml2ZXMKd2l0aG91dCByZWJvb3RpbmcuCgot
LSAKVGltIFJvYmVydHMsIHRpbXJAcHJvYm8uY29tClByb3ZpZGVuemEgJiBCb2VrZWxoZWlkZSwg
SW5jLgoKCi0tLQpOVERFViBpcyBzcG9uc29yZWQgYnkgT1NSCgpWaXNpdCB0aGUgbGlzdCBhdDog
aHR0cDovL3d3dy5vc3JvbmxpbmUuY29tL3Nob3dsaXN0cy5jZm0/bGlzdD1udGRldgoKT1NSIGlz
IEhJUklORyEhICBTZWUgaHR0cDovL3d3dy5vc3IuY29tL2NhcmVlcnMKCkZvciBvdXIgc2NoZWR1
bGUgb2YgV0RGLCBXRE0sIGRlYnVnZ2luZyBhbmQgb3RoZXIgc2VtaW5hcnMgdmlzaXQ6IApodHRw
Oi8vd3d3Lm9zci5jb20vc2VtaW5hcnMKClRvIHVuc3Vic2NyaWJlLCB2aXNpdCB0aGUgTGlzdCBT
ZXJ2ZXIgc2VjdGlvbiBvZiBPU1IgT25saW5lIGF0IGh0dHA6Ly93d3cub3Nyb25saW5lLmNvbS9w
YWdlLmNmbT9uYW1lPUxpc3RTZXJ2ZXIKCi0tLSAKTlRERVYgaXMgc3BvbnNvcmVkIGJ5IE9TUiAK
ClZpc2l0IHRoZSBsaXN0IGF0OiBodHRwOi8vd3d3Lm9zcm9ubGluZS5jb20vc2hvd2xpc3RzLmNm
bT9saXN0PW50ZGV2IAoKT1NSIGlzIEhJUklORyEhIFNlZSBodHRwOi8vd3d3Lm9zci5jb20vY2Fy
ZWVycyAKCkZvciBvdXIgc2NoZWR1bGUgb2YgV0RGLCBXRE0sIGRlYnVnZ2luZyBhbmQgb3RoZXIg
c2VtaW5hcnMgdmlzaXQ6IApodHRwOi8vd3d3Lm9zci5jb20vc2VtaW5hcnMgCgpUbyB1bnN1YnNj
cmliZSwgdmlzaXQgdGhlIExpc3QgU2VydmVyIHNlY3Rpb24gb2YgT1NSIE9ubGluZSBhdCBodHRw
Oi8vd3d3Lm9zcm9ubGluZS5jb20vcGFnZS5jZm0/bmFtZT1MaXN0U2VydmVyCgotLS0gCk5UREVW
IGlzIHNwb25zb3JlZCBieSBPU1IgCgpWaXNpdCB0aGUgbGlzdCBhdDogaHR0cDovL3d3dy5vc3Jv
bmxpbmUuY29tL3Nob3dsaXN0cy5jZm0/bGlzdD1udGRldiAKCk9TUiBpcyBISVJJTkchISBTZWUg
aHR0cDovL3d3dy5vc3IuY29tL2NhcmVlcnMgCgpGb3Igb3VyIHNjaGVkdWxlIG9mIFdERiwgV0RN
LCBkZWJ1Z2dpbmcgYW5kIG90aGVyIHNlbWluYXJzIHZpc2l0OiAKaHR0cDovL3d3dy5vc3IuY29t
L3NlbWluYXJzIAoKVG8gdW5zdWJzY3JpYmUsIHZpc2l0IHRoZSBMaXN0IFNlcnZlciBzZWN0aW9u
IG9mIE9TUiBPbmxpbmUgYXQgaHR0cDovL3d3dy5vc3JvbmxpbmUuY29tL3BhZ2UuY2ZtP25hbWU9
TGlzdFNlcnZlcg==
–
test
You would, of course, still need to reboot to install both drivers the first
time. This technique is useful though for eliminating future reboots to
update the functionality component.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
For update: what about splitting your driver into 2 components ? The first
one will be just a place holder in the stack but all the core logic is in
2nd one that you can dynamically load/unload. At load time 2nd one can
provide its function pointers to the first one [e.g. using an IOCTL]. The
first one will also need some logic to pause/resume Irps momentarily when
the load/unload process happens.
Just a thought.
Yes, this is how FltMgr is architected.
wrote in message news:xxxxx@ntdev…
> For update: what about splitting your driver into 2 components ? The first one will be just a place holder in the stack but all the core logic is in 2nd one that you can dynamically load/unload. At load time 2nd one can provide its function pointers to the first one [e.g. using an IOCTL]. The first one will also need some logic to pause/resume Irps momentarily when the load/unload process happens.
>
> Just a thought.
>
>different type of filter attachment such as dispatch hooks. But here again there is now another issue
in hyper-v that was discussed in another thread that one of the Microsoft filter drivers
Yes, and MS’s people here were speaking about the next Hyper-V abandoning the SCSI model for disk IO.
But, for volume filters, this is never mind.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
The technique can be used successfully, but the OP should be aware that it
can be a challenge to do correctly. Depending on what the filter is doing,
removing a filter from an active drive and replacing it can have a lot of
challenges. If you have state that is needed, you will have to have it in
the actual filter that sits in the stack, but that constrains the support
driver since the state must stay common, or else be derivable with a version
numbering schema. It can work, but it not worth the effort in most cases.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, April 04, 2014 9:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Install/Update a DiskDrive filter driver without reboot
You would, of course, still need to reboot to install both drivers the first
time. This technique is useful though for eliminating future reboots to
update the functionality component.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
For update: what about splitting your driver into 2 components ? The first
one will be just a place holder in the stack but all the core logic is in
2nd one that you can dynamically load/unload. At load time 2nd one can
provide its function pointers to the first one [e.g. using an IOCTL]. The
first one will also need some logic to pause/resume Irps momentarily when
the load/unload process happens.
Just a thought.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Good point. It’s also difficult to validate that you’ve done it correctly,
there’s a lot of races that can happen.
-scott
OSR
@OSRDrivers
“Don Burn” wrote in message news:xxxxx@ntdev…
The technique can be used successfully, but the OP should be aware that it
can be a challenge to do correctly. Depending on what the filter is doing,
removing a filter from an active drive and replacing it can have a lot of
challenges. If you have state that is needed, you will have to have it in
the actual filter that sits in the stack, but that constrains the support
driver since the state must stay common, or else be derivable with a version
numbering schema. It can work, but it not worth the effort in most cases.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, April 04, 2014 9:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Install/Update a DiskDrive filter driver without reboot
You would, of course, still need to reboot to install both drivers the first
time. This technique is useful though for eliminating future reboots to
update the functionality component.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
For update: what about splitting your driver into 2 components ? The first
one will be just a place holder in the stack but all the core logic is in
2nd one that you can dynamically load/unload. At load time 2nd one can
provide its function pointers to the first one [e.g. using an IOCTL]. The
first one will also need some logic to pause/resume Irps momentarily when
the load/unload process happens.
Just a thought.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Thanks. In fact, I already have the logic implemented in different components which makes it much easier to break it apart. However, the first part still needs to keep track of W/R requests (not necessarily pausing them) during load/unload of the second part. Theoretically, the OS should be capable of doing this; apparently it does not in practice.
By the way, if I want to go with this solution how should I implement that dynamic load/unload part? Any documentation/sample/guideline?
@Erikson
Probably I should correct my statement as:
“In fact, I am trying to filter every and all …”
Now, apart from the after-market drivers that may bypass the stack is there any thing else that I should be worry about? I mean, having a conventional VM configuration, is not my solution good enough to filter all writes to the disk; noting that I have not experienced any problem on any of my W2K3, and W2K8 test machines to this point.