I would like to know, that the events registered through
IoRegisterPlugPlayNotification like VOLUME_LOCK, VOLUME_DISMOUNT, when are
they fired? and it must be async in nature, the thread processing the actual
volume dismount would not wait for the consumers of the event to complete
their task right?
IS there a way to make this a blocking call for the consumer? So that the
processing the consumer does on these events will be done fist and the
actual dismount/locl/unlock happens?
We are at a volume level and need to process lock and unlock on volumes, and
dismount.
>I would like to know, that the events registered through
IoRegisterPlugPlayNotification like VOLUME_LOCK, VOLUME_DISMOUNT, when >are
they fired?
With respect to these two in particular, the volume lock notification is
sent by the file system at the beginning of its FSCTL_LOCK_VOLUME
processing. The same with volume dismount, it’s sent at the beginning of
FSCTL_DISMOUNT_VOLUME processing. FSDs typically use FsRtlNotifyVolumeEvent
to send the notification, so you can search the FASTFAT source for that API
as an example.
it must be async in nature, the thread processing the actual volume
dismount would not wait for the consumers of the event to complete >their
task right?
Nope, they are sent synchronously. The point of these notifications is that
the FSD is about to try to lock or dismount the volume, so it needs everyone
to close anything that they don’t need (e.g. directory change notifications)
to give the lock/dismount the best chance of succeeding.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc. http://www.osronline.com
“Bedanto” wrote in message news:xxxxx@ntdev… folks,
greetings!
I would like to know, that the events registered through IoRegisterPlugPlayNotification like VOLUME_LOCK, VOLUME_DISMOUNT, when are they fired? and it must be async in nature, the thread processing the actual volume dismount would not wait for the consumers of the event to complete their task right?
IS there a way to make this a blocking call for the consumer? So that the processing the consumer does on these events will be done fist and the actual dismount/locl/unlock happens?
We are at a volume level and need to process lock and unlock on volumes, and dismount.
Thanks for the clarification scott. I have seen that in chkdsk or format, if
the Volume lock fails they promt us to approve a force dismount of teh
volume. We also have a VOLUME_DISMOUNT_FAILED event. The docs say that even
dismount can fail due to open handles, but I have never seen any such case
where handles couldn’t be closed. So can you give me an example where this
will occur?
Also is there a way to know the states of the events after completion, I
mean I know that volume is being dismounted and if it fails I get another
event saying so, but how do I determine teh success? is there a call back
for that?
Also, wahat is FSRTL_VOLUME_BACKGROUND_FORMAT? When is this one used? MSDN
doesnt have a link for it…
On Mon, Feb 7, 2011 at 8:18 PM, Scott Noone wrote:
> I would like to know, that the events registered through >> IoRegisterPlugPlayNotification like VOLUME_LOCK, VOLUME_DISMOUNT, when >are >> they fired? >> > > With respect to these two in particular, the volume lock notification is > sent by the file system at the beginning of its FSCTL_LOCK_VOLUME > processing. The same with volume dismount, it’s sent at the beginning of > FSCTL_DISMOUNT_VOLUME processing. FSDs typically use FsRtlNotifyVolumeEvent > to send the notification, so you can search the FASTFAT source for that API > as an example. > > > it must be async in nature, the thread processing the actual volume >> dismount would not wait for the consumers of the event to complete >their >> task right? >> > > Nope, they are sent synchronously. The point of these notifications is that > the FSD is about to try to lock or dismount the volume, so it needs everyone > to close anything that they don’t need (e.g. directory change notifications) > to give the lock/dismount the best chance of succeeding. > > -scott > > – > Scott Noone > Consulting Associate and Chief System Problem Analyst > OSR Open Systems Resources, Inc. > http://www.osronline.com > > “Bedanto” wrote in message news:xxxxx@ntdev… > > folks, > > greetings! > > I would like to know, that the events registered through > IoRegisterPlugPlayNotification like VOLUME_LOCK, VOLUME_DISMOUNT, when are > they fired? and it must be async in nature, the thread processing the actual > volume dismount would not wait for the consumers of the event to complete > their task right? > > IS there a way to make this a blocking call for the consumer? So that the > processing the consumer does on these events will be done fist and the > actual dismount/locl/unlock happens? > > We are at a volume level and need to process lock and unlock on volumes, > and dismount. > > thanks > > bedanto > > — > 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 >
>The docs say that even dismount can fail due to open handles, but I have
never seen any such case where handles couldn’t be closed. >So can you give
me an example where this will occur?
It can happen with any application that doesn’t listen for the volume
notification events and close its handles.
Also is there a way to know the states of the events after completion, I
mean I know that volume is being dismounted and if it fails I get >another
event saying so, but how do I determine teh success? is there a call back
for that?
The only way that I know of to get this notification would be from a file
system filter driver (with a FSF you can check the completion status in
post-dismount processing).
Also, wahat is FSRTL_VOLUME_BACKGROUND_FORMAT? When is this one used? MSDN
doesnt have a link for it…
Looks to be something to do with UDFS, other than that I’m not sure.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc. http://www.osronline.com
>It can happen with any application that doesn’t listen for the volume
notification events and close its handles.
(my bad, i should have been more detailed) well, we have a driver which
opens a kernel mode handle and when a volume lock comes we dont close it. i
see chkdsk going ahead and dismounting the volume, so i had assumed that
dismount would happen disregarding the appsdrivers open handle count. so a
dismount failure shouldnt happen, atleast not for open handles…
unfortunately we r not an fsf so we have to rely on these events as the best
bet…
On Tue, Feb 8, 2011 at 12:10 AM, Scott Noone wrote:
> The docs say that even dismount can fail due to open handles, but I have >> never seen any such case where handles couldn’t be closed. >So can you give >> me an example where this will occur? >> > > It can happen with any application that doesn’t listen for the volume > notification events and close its handles. > > > Also is there a way to know the states of the events after completion, I >> mean I know that volume is being dismounted and if it fails I get >another >> event saying so, but how do I determine teh success? is there a call back >> for that? >> > > The only way that I know of to get this notification would be from a file > system filter driver (with a FSF you can check the completion status in > post-dismount processing). > > > Also, wahat is FSRTL_VOLUME_BACKGROUND_FORMAT? When is this one used? MSDN >> doesnt have a link for it… >> > > Looks to be something to do with UDFS, other than that I’m not sure. > > > -scott > > – > Scott Noone > Consulting Associate and Chief System Problem Analyst > OSR Open Systems Resources, Inc. > http://www.osronline.com > > > — > 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 >
>so i had assumed that dismount would happen disregarding the appsdrivers
open handle count. so a dismount failure shouldnt happen, >atleast not for
open handles…
Did you open the file for write access? If you did I’d expect the autochk to
fail (tracked this exact type of bug down recently, actually). If not it’s
sort of interesting though the rules around lock/dismount/eject/remove can
be subtle and confusing. Sounds like you don’t care much though.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc. http://www.osronline.com
yeah write access and also the file was pinned. bot hformat and chkdsk went
ahead after I pressed yes in the warning for force dismount. this is on
xp32sp3 BTW, just an FYI.
No we do care, hence all the emails we need to close the handles in this
notification, the subsequent writes using those stale handles are leading to
some ugly blue screens
On Tue, Feb 8, 2011 at 1:19 AM, Scott Noone wrote:
> so i had assumed that dismount would happen disregarding the appsdrivers >> open handle count. so a dismount failure shouldnt happen, >atleast not for >> open handles… >> > > Did you open the file for write access? If you did I’d expect the autochk > to fail (tracked this exact type of bug down recently, actually). If not > it’s sort of interesting though the rules around lock/dismount/eject/remove > can be subtle and confusing. Sounds like you don’t care much though. > > > -scott > > – > Scott Noone > Consulting Associate and Chief System Problem Analyst > OSR Open Systems Resources, Inc. > http://www.osronline.com > > — > 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 >
There is a sample in the WDK, MetadataManager, which should show how and
when a minifilter that keeps a handle open to a file should close that file.
Thanks,
Alex.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Monday, February 07, 2011 12:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IoRegisterPlugPlayNotification Routine
yeah write access and also the file was pinned. bot hformat and chkdsk went
ahead after I pressed yes in the warning for force dismount. this is on
xp32sp3 BTW, just an FYI.
No we do care, hence all the emails we need to close the handles in this
notification, the subsequent writes using those stale handles are leading to
some ugly blue screens
On Tue, Feb 8, 2011 at 1:19 AM, Scott Noone wrote:
so i had assumed that dismount would happen disregarding the appsdrivers open handle count. so a dismount failure shouldnt happen, >atleast not for open handles…
Did you open the file for write access? If you did I’d expect the autochk to fail (tracked this exact type of bug down recently, actually). If not it’s sort of interesting though the rules around lock/dismount/eject/remove can be subtle and confusing. Sounds like you don’t care much though.
-scott
– Scott Noone Consulting Associate and Chief System Problem Analyst OSR Open Systems Resources, Inc. http://www.osronline.comhttp:</http:>
> There is a sample in the WDK, MetadataManager, which should show how and > when a minifilter that keeps a handle open to a file should close that file. > > > > Thanks, > > Alex. > > > > From:xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] *On Behalf Of *Bedanto > Sent: Monday, February 07, 2011 12:00 PM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] IoRegisterPlugPlayNotification Routine > > > > yeah write access and also the file was pinned. bot hformat and chkdsk went > ahead after I pressed yes in the warning for force dismount. this is on > xp32sp3 BTW, just an FYI. > > > > No we do care, hence all the emails we need to close the handles in this > notification, the subsequent writes using those stale handles are leading to > some ugly blue screens > > On Tue, Feb 8, 2011 at 1:19 AM, Scott Noone wrote: > > so i had assumed that dismount would happen disregarding the appsdrivers > open handle count. so a dismount failure shouldnt happen, >atleast not for > open handles… > > > > Did you open the file for write access? If you did I’d expect the autochk > to fail (tracked this exact type of bug down recently, actually). If not > it’s sort of interesting though the rules around lock/dismount/eject/remove > can be subtle and confusing. Sounds like you don’t care much though. > > > > -scott > > – > Scott Noone > Consulting Associate and Chief System Problem Analyst > OSR Open Systems Resources, Inc. > http://www.osronline.com > > — > 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 > > > — 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 > > — > 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 >
another quick qn on this related topic is that on this xp sp3 32 bit
(running as a vmware guest) i see for a single format operation multiple
volume locks being fired one after the other in a series. after that a
series of dismounts then finally a series of unlocks, mounts and a series of
volume name change.
is this standard behaviour? would expect only one of each kind…
On Tue, Feb 8, 2011 at 2:00 AM, Bedanto wrote:
> yeah, but unfortunately we r not in the fs stack… > > > On Tue, Feb 8, 2011 at 1:47 AM, Alex Carp wrote: > >> There is a sample in the WDK, MetadataManager, which should show how and >> when a minifilter that keeps a handle open to a file should close that file. >> >> >> >> Thanks, >> >> Alex. >> >> >> >> From:xxxxx@lists.osr.com [mailto: >> xxxxx@lists.osr.com] *On Behalf Of *Bedanto >> Sent: Monday, February 07, 2011 12:00 PM >> To: Windows System Software Devs Interest List >> Subject: Re: [ntdev] IoRegisterPlugPlayNotification Routine >> >> >> >> yeah write access and also the file was pinned. bot hformat and chkdsk >> went ahead after I pressed yes in the warning for force dismount. this is on >> xp32sp3 BTW, just an FYI. >> >> >> >> No we do care, hence all the emails we need to close the handles in >> this notification, the subsequent writes using those stale handles are >> leading to some ugly blue screens >> >> On Tue, Feb 8, 2011 at 1:19 AM, Scott Noone wrote: >> >> so i had assumed that dismount would happen disregarding the appsdrivers >> open handle count. so a dismount failure shouldnt happen, >atleast not for >> open handles… >> >> >> >> Did you open the file for write access? If you did I’d expect the autochk >> to fail (tracked this exact type of bug down recently, actually). If not >> it’s sort of interesting though the rules around lock/dismount/eject/remove >> can be subtle and confusing. Sounds like you don’t care much though. >> >> >> >> -scott >> >> – >> Scott Noone >> Consulting Associate and Chief System Problem Analyst >> OSR Open Systems Resources, Inc. >> http://www.osronline.com >> >> — >> 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 >> >> >> — 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 >> >> — >> 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 >> > >
>No we do care, hence all the emails we need to close the handles in this
notification, the subsequent writes using those stale >handles are leading
to some ugly blue screens
The crashes are a separate issue, though your driver should be bullet proof
when it comes to those writes failing (writes aren’t guaranteed to never
fail outside of this situation).
Why can’t you just close the handle when you get this notification? Is it
because you don’t know when to open it again? When do you open it in the
first place?
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc. http://www.osronline.com
yes, we close the handle at lock or dismount event. we were *not* doing so
before, because we were not registered to the events. and we would blindly
be using the stale handle to perform io after lockdismount, causing
deadlocks and bsods.
now we are able to close the handles.
yes, you are right, we need to figure out where to reopen them again,
perhaps in volume mountunlock. as of now we open them on fsmount.
but i still am at a loss to explain the multiple occurances of the same
event. am i supposed to set a flag somewhere to get each event only once
On Tue, Feb 8, 2011 at 8:02 PM, Scott Noone wrote:
> No we do care, hence all the emails we need to close the handles in >> this notification, the subsequent writes using those stale >handles are >> leading to some ugly blue screens >> > > The crashes are a separate issue, though your driver should be bullet proof > when it comes to those writes failing (writes aren’t guaranteed to never > fail outside of this situation). > > Why can’t you just close the handle when you get this notification? Is it > because you don’t know when to open it again? When do you open it in the > first place? > > > -scott > > – > Scott Noone > Consulting Associate and Chief System Problem Analyst > OSR Open Systems Resources, Inc. > http://www.osronline.com > > > — > 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 >
we need to close the handles in this