IRP_MN_QUERY_DEVICE_RELATIONS concurrency

Is it possible to receive another IRP_MN_QUERY_DEVICE_RELATIONS for
BusRelations while handling a different IRP_MN_QUERY_DEVICE_RELATIONS
for BusRelations? (say on Windows 2000)

I assumed not because I found no documentation for it. I have seen
that white paper on IRP concurrency, but it failed to mention this
one. I see "context of a system thread" mentioned in the DDK docs,
which makes me think that might be the same system thread that sends
IRP_MN_START_DEVICE, IRP_MN_STOP_DEVICE, and IRP_MN_REMOVE_DEVICE.

Maybe I should just send every PnP IRP through my own worker thread,
then I won't have to think about whether the OS serializes this PnP
IRP or that one and why it does some and not others. I can't imagine
PnP IRPs happen that often, so I can't imagine it'd be any sort of a
performance bottleneck.

Doron
Fri Dec 22 19:53:35 CST 2006

serializing everything to a thread is a bit overkill. QDR/BusRelations is a
state changing irp. that means it is serialized against itself and other
state changing (start, stop, remove, surprise remove, query stop, query
remove, q.s. canceled, q.r. canceled) irps.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:02voo2hsrj9rg6osmhvpvbbosaa111f9c7@4ax.com...
> Is it possible to receive another IRP_MN_QUERY_DEVICE_RELATIONS for
> BusRelations while handling a different IRP_MN_QUERY_DEVICE_RELATIONS
> for BusRelations? (say on Windows 2000)
>
> I assumed not because I found no documentation for it. I have seen
> that white paper on IRP concurrency, but it failed to mention this
> one. I see "context of a system thread" mentioned in the DDK docs,
> which makes me think that might be the same system thread that sends
> IRP_MN_START_DEVICE, IRP_MN_STOP_DEVICE, and IRP_MN_REMOVE_DEVICE.
>
> Maybe I should just send every PnP IRP through my own worker thread,
> then I won't have to think about whether the OS serializes this PnP
> IRP or that one and why it does some and not others. I can't imagine
> PnP IRPs happen that often, so I can't imagine it'd be any sort of a
> performance bottleneck.
>

BubbaGump
Sat Dec 23 09:41:47 CST 2006

Okay, handling everything one at a time would hurt concurrency a bit
(although I'm still trying to imagine what PnP operation might wait on
something for so long that it would be noticeable).

Anyway, I thought you might mention that BusRelations is already
serialized. You alluded to it the other day, but another IRP I would
have expected to be serialized with all these is
IRP_MN_DEVICE_USAGE_NOTIFICATION, and I think I heard a while ago that
it's not. Is there some document I'm not reading that might point out
the orientation of all these IRPs, or should I assume "context of a
system thread" always refers to the same system thread as the
state-changing IRPs? I was initially misled by the great detail of
"Multiprocessor Considerations for Kernel-Mode Drivers" but absence of
any mention of IRP_MN_QUERY_DEVICE_RELATIONS (BusRelations or other).




On Fri, 22 Dec 2006 17:53:35 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>serializing everything to a thread is a bit overkill. QDR/BusRelations is a
>state changing irp. that means it is serialized against itself and other
>state changing (start, stop, remove, surprise remove, query stop, query
>remove, q.s. canceled, q.r. canceled) irps.
>
>d

Tim
Sun Dec 24 18:57:32 CST 2006

BubbaGump <> wrote:
>
>Okay, handling everything one at a time would hurt concurrency a bit
>(although I'm still trying to imagine what PnP operation might wait on
>something for so long that it would be noticeable).
>
>Anyway, I thought you might mention that BusRelations is already
>serialized. You alluded to it the other day, but another IRP I would
>have expected to be serialized with all these is
>IRP_MN_DEVICE_USAGE_NOTIFICATION, and I think I heard a while ago that
>it's not.

That IRP doesn't change change state, so serialization isn't particularly
important. It's a query only. In addition, that IRP only applies to
drivers for devices that can contain a paging file, a dump file, or a
hibernation file. That's a very narrow class of drivers.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

BubbaGump
Sun Dec 24 21:19:36 CST 2006

On Sun, 24 Dec 2006 16:57:32 -0800, Tim Roberts <timr@probo.com>
wrote:

>BubbaGump <> wrote:
>>
>>Okay, handling everything one at a time would hurt concurrency a bit
>>(although I'm still trying to imagine what PnP operation might wait on
>>something for so long that it would be noticeable).
>>
>>Anyway, I thought you might mention that BusRelations is already
>>serialized. You alluded to it the other day, but another IRP I would
>>have expected to be serialized with all these is
>>IRP_MN_DEVICE_USAGE_NOTIFICATION, and I think I heard a while ago that
>>it's not.
>
>That IRP doesn't change change state, so serialization isn't particularly
>important. It's a query only. In addition, that IRP only applies to
>drivers for devices that can contain a paging file, a dump file, or a
>hibernation file. That's a very narrow class of drivers.

IRP_MN_DEVICE_USAGE_NOTIFICATION does change state because being used
for a paging file, a dump file, or a hibernation file is state that
must be taken into account by IRP_MN_QUERY_REMOVE_DEVICE. If a device
is being used for one of those things, then IRP_MN_QUERY_REMOVE_DEVICE
should fail and not allow PnP state to change to remove-pending. If
PnP state is already remove-pending, then
IRP_MN_DEVICE_USAGE_NOTIFICATION should fail and not allow the device
to be used for one of those things. It's not just a query. It's a
query and a change of state (a test-and-set) from both perspectives.
Serialization is important to avoid a race and prevent device usage
from co-existing with a conflicting PnP state.

I suppose it only applies to storage drivers and all other drivers
would just fail IRP_MN_DEVICE_USAGE_NOTIFICATION, but if the location
in the OS that sends IRP_MN_DEVICE_USAGE_NOTIFICATION was common for
all drivers then serializing it would help the drivers that use it
without hurting the ones that don't. If the OS doesn't serialize and
the driver has to, then I agree that drivers that don't support it
should be able to just fail it without doing anything else.

Doron
Mon Dec 25 11:41:13 CST 2006

usage notifications are usually sent during the start path. note that other
irps that could lead to a query remove failure (like create, query
interface) are not syncronized with pnp state changing irps either. the key
here is if another driver is allowed to send the pnp minor irp, it is not
synchronized with any pnp state changing irp.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:viguo25caqedjmb9lolj89kgi96okk5usc@4ax.com...
> On Sun, 24 Dec 2006 16:57:32 -0800, Tim Roberts <timr@probo.com>
> wrote:
>
>>BubbaGump <> wrote:
>>>
>>>Okay, handling everything one at a time would hurt concurrency a bit
>>>(although I'm still trying to imagine what PnP operation might wait on
>>>something for so long that it would be noticeable).
>>>
>>>Anyway, I thought you might mention that BusRelations is already
>>>serialized. You alluded to it the other day, but another IRP I would
>>>have expected to be serialized with all these is
>>>IRP_MN_DEVICE_USAGE_NOTIFICATION, and I think I heard a while ago that
>>>it's not.
>>
>>That IRP doesn't change change state, so serialization isn't particularly
>>important. It's a query only. In addition, that IRP only applies to
>>drivers for devices that can contain a paging file, a dump file, or a
>>hibernation file. That's a very narrow class of drivers.
>
> IRP_MN_DEVICE_USAGE_NOTIFICATION does change state because being used
> for a paging file, a dump file, or a hibernation file is state that
> must be taken into account by IRP_MN_QUERY_REMOVE_DEVICE. If a device
> is being used for one of those things, then IRP_MN_QUERY_REMOVE_DEVICE
> should fail and not allow PnP state to change to remove-pending. If
> PnP state is already remove-pending, then
> IRP_MN_DEVICE_USAGE_NOTIFICATION should fail and not allow the device
> to be used for one of those things. It's not just a query. It's a
> query and a change of state (a test-and-set) from both perspectives.
> Serialization is important to avoid a race and prevent device usage
> from co-existing with a conflicting PnP state.
>
> I suppose it only applies to storage drivers and all other drivers
> would just fail IRP_MN_DEVICE_USAGE_NOTIFICATION, but if the location
> in the OS that sends IRP_MN_DEVICE_USAGE_NOTIFICATION was common for
> all drivers then serializing it would help the drivers that use it
> without hurting the ones that don't. If the OS doesn't serialize and
> the driver has to, then I agree that drivers that don't support it
> should be able to just fail it without doing anything else.
>

Tim
Tue Dec 26 20:53:29 CST 2006

BubbaGump <> wrote:
>
>IRP_MN_DEVICE_USAGE_NOTIFICATION does change state because being used
>for a paging file, a dump file, or a hibernation file is state that
>must be taken into account by IRP_MN_QUERY_REMOVE_DEVICE.

No, IRP_MN_DEVICE_USAGE_NOTIFICATION does not change the state of the
driver. The driver simply returns a hard-coded constant value, true or
false.

>If a device
>is being used for one of those things, then IRP_MN_QUERY_REMOVE_DEVICE
>should fail and not allow PnP state to change to remove-pending.

If a device is being used for one of those things, then the operating
system will not try to remove the device.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Maxim
Wed Dec 27 04:51:30 CST 2006

> No, IRP_MN_DEVICE_USAGE_NOTIFICATION does not change the state of
>the
> driver. The driver simply returns a hard-coded constant value, true or
> false.

It changes the state of power management paths.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

BubbaGump
Wed Dec 27 11:25:11 CST 2006

On Tue, 26 Dec 2006 18:53:29 -0800, Tim Roberts <timr@probo.com>
wrote:

>BubbaGump <> wrote:
>>
>>IRP_MN_DEVICE_USAGE_NOTIFICATION does change state because being used
>>for a paging file, a dump file, or a hibernation file is state that
>>must be taken into account by IRP_MN_QUERY_REMOVE_DEVICE.
>
>No, IRP_MN_DEVICE_USAGE_NOTIFICATION does not change the state of the
>driver. The driver simply returns a hard-coded constant value, true or
>false.
>
>>If a device
>>is being used for one of those things, then IRP_MN_QUERY_REMOVE_DEVICE
>>should fail and not allow PnP state to change to remove-pending.
>
>If a device is being used for one of those things, then the operating
>system will not try to remove the device.


I wish that were true, but that is not what is stated in "Handling an
IRP_MN_QUERY_REMOVE_DEVICE Request" in the DDK docs:

"A driver must fail a query-remove IRP if any of the following
are true:

...

If a driver has been notified (through an
IRP_MN_DEVICE_USAGE_NOTIFICATION IRP) that the device is in the path
for a paging, crash dump, or hibernation file."

Doron
Wed Dec 27 12:07:30 CST 2006

IRP_MN_USAGE_NOTIFICATION is not tied to pnp state directly. you can tell
b/c as i indicated earlier, if another driver can the irp (which any driver
can), then it is not part of the pnp state machine maintained by the pnp
manager. fortunately, this irp is sent well before a q.r. can be sent so
you don't have to worry too much about synchronizing with q.r. ... as maxim
said, you do have to make sure that you are not power pagable anymore if you
succeed any of the usages.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:ava5p2p74a9spj1hlb8lb192s1vfm6fnsb@4ax.com...
> On Tue, 26 Dec 2006 18:53:29 -0800, Tim Roberts <timr@probo.com>
> wrote:
>
>>BubbaGump <> wrote:
>>>
>>>IRP_MN_DEVICE_USAGE_NOTIFICATION does change state because being used
>>>for a paging file, a dump file, or a hibernation file is state that
>>>must be taken into account by IRP_MN_QUERY_REMOVE_DEVICE.
>>
>>No, IRP_MN_DEVICE_USAGE_NOTIFICATION does not change the state of the
>>driver. The driver simply returns a hard-coded constant value, true or
>>false.
>>
>>>If a device
>>>is being used for one of those things, then IRP_MN_QUERY_REMOVE_DEVICE
>>>should fail and not allow PnP state to change to remove-pending.
>>
>>If a device is being used for one of those things, then the operating
>>system will not try to remove the device.
>
>
> I wish that were true, but that is not what is stated in "Handling an
> IRP_MN_QUERY_REMOVE_DEVICE Request" in the DDK docs:
>
> "A driver must fail a query-remove IRP if any of the following
> are true:
>
> ...
>
> If a driver has been notified (through an
> IRP_MN_DEVICE_USAGE_NOTIFICATION IRP) that the device is in the path
> for a paging, crash dump, or hibernation file."
>

BubbaGump
Wed Dec 27 14:56:52 CST 2006

Not have to worry too much? Yes, a race is unlikely but software
should be designed without any race conditions except special
situations where all possible outcomes of the race can be handled
safely ("safely" being open to interpretation).

In this situation, one of the possible outcomes is unsafe (could lead
to an in-use resource being freed). The probability that it will
happen is irrelevant.




On Wed, 27 Dec 2006 10:07:30 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>IRP_MN_USAGE_NOTIFICATION is not tied to pnp state directly. you can tell
>b/c as i indicated earlier, if another driver can the irp (which any driver
>can), then it is not part of the pnp state machine maintained by the pnp
>manager. fortunately, this irp is sent well before a q.r. can be sent so
>you don't have to worry too much about synchronizing with q.r. ... as maxim
>said, you do have to make sure that you are not power pagable anymore if you
>succeed any of the usages.
>
>d

BubbaGump
Wed Dec 27 19:53:02 CST 2006

Okay, no answer to this, so maybe the documentation is lacking. In
the absence of both source code _and_ documentation, I guess
information comes from arbitrary newsgroup postings by internal
developers.


On Sat, 23 Dec 2006 10:41:51 -0500, BubbaGump <> wrote:

>Is there some document I'm not reading that might point out
>the orientation of all these IRPs, or should I assume "context of a
>system thread" always refers to the same system thread as the
>state-changing IRPs? I was initially misled by the great detail of
>"Multiprocessor Considerations for Kernel-Mode Drivers" but absence of
>any mention of IRP_MN_QUERY_DEVICE_RELATIONS (BusRelations or other).


On Fri, 22 Dec 2006 17:53:35 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>QDR/BusRelations is a
>state changing irp. that means it is serialized against itself and other
>state changing (start, stop, remove, surprise remove, query stop, query
>remove, q.s. canceled, q.r. canceled) irps.

BubbaGump
Wed Dec 27 21:32:46 CST 2006

It's surprising there's been so much discussion about
IRP_MN_DEVICE_USAGE_NOTIFICATION. Typing "irp_mn_d" into the Index
tab of the DDK docs repeats everything that's been said:


"For a ... file created on its device, a driver must do the
following:

* Lock code in memory for its DispatchRead, DispatchWrite,
DispatchDeviceControl, and DispatchPower routines.
...
* Clear the DO_POWER_PAGABLE bit in its device object for the
device (on the IRP's way up the device stack).
* Fail IRP_MN_QUERY_STOP_DEVICE and IRP_MN_QUERY_REMOVE_DEVICE
requests for the device."


Are there alternate ways to interpret this?




On Wed, 27 Dec 2006 10:07:30 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>IRP_MN_USAGE_NOTIFICATION is not tied to pnp state directly. you can tell
>b/c as i indicated earlier, if another driver can the irp (which any driver
>can), then it is not part of the pnp state machine maintained by the pnp
>manager. fortunately, this irp is sent well before a q.r. can be sent so
>you don't have to worry too much about synchronizing with q.r. ... as maxim
>said, you do have to make sure that you are not power pagable anymore if you
>succeed any of the usages.

BubbaGump
Wed Dec 27 23:10:32 CST 2006

That should have read, "I assumed not, but I found no documentation
for it."

("but" instead of "because")




On Fri, 22 Dec 2006 20:08:04 -0500, BubbaGump <> wrote:

>Is it possible to receive another IRP_MN_QUERY_DEVICE_RELATIONS for
>BusRelations while handling a different IRP_MN_QUERY_DEVICE_RELATIONS
>for BusRelations? (say on Windows 2000)
>
>I assumed not because I found no documentation for it.

BubbaGump
Thu Dec 28 08:08:12 CST 2006

I guess what I'm saying is that while subjective analysis from
internal developers is useful, it would be more useful for objective
design constraints to be documented.

The serialization of a group of IRPs is already documented. When an
internal developer mentions an additional IRP in that group, how can
external developers depend on that being true in the future if it is
undocumented? What's to stop it from being changed with the reasoning
that the functionality is undocumented and shouldn't be depended on?




On Wed, 27 Dec 2006 20:53:05 -0500, BubbaGump <> wrote:

>Okay, no answer to this, so maybe the documentation is lacking. In
>the absence of both source code _and_ documentation, I guess
>information comes from arbitrary newsgroup postings by internal
>developers.
>
>
>On Sat, 23 Dec 2006 10:41:51 -0500, BubbaGump <> wrote:
>
>>Is there some document I'm not reading that might point out
>>the orientation of all these IRPs, or should I assume "context of a
>>system thread" always refers to the same system thread as the
>>state-changing IRPs? I was initially misled by the great detail of
>>"Multiprocessor Considerations for Kernel-Mode Drivers" but absence of
>>any mention of IRP_MN_QUERY_DEVICE_RELATIONS (BusRelations or other).
>
>
>On Fri, 22 Dec 2006 17:53:35 -0800, "Doron Holan [MS]"
><doronh@nospam.microsoft.com> wrote:
>
>>QDR/BusRelations is a
>>state changing irp. that means it is serialized against itself and other
>>state changing (start, stop, remove, surprise remove, query stop, query
>>remove, q.s. canceled, q.r. canceled) irps.

BubbaGump
Thu Dec 28 10:11:06 CST 2006

I do question the idea of safety in this situation. If
IRP_MN_DEVICE_USAGE_NOTIFICATION was succeeded after
IRP_MN_QUERY_REMOVE_DEVICE then wouldn't the paging, crash dump, or
hibernation file still need to be opened on the device, and isn't
opening a file on a device synchronized with
IRP_MN_QUERY_REMOVE_DEVICE in Windows 2000 and later? Perhaps this is
what Tim meant? I suppose IRP_MN_DEVICE_USAGE_NOTIFICATION in this
situation is slightly redundant and would only prevent an error
message that the file could not be opened from popping up later.

That still leaves IRP_MN_QUERY_STOP_DEVICE. The OS doesn't
synchronize IRP_MN_QUERY_STOP_DEVICE with file opens, does it? What
if the device was stopped while being used for a paging file?
IRP_MN_QUERY_STOP_DEVICE is only for resource re-balancing, so it
would only temporarily stop paging, right? Is any of the OS code that
sends IRP_MN_QUERY_STOP_DEVICE or IRP_MN_STOP_DEVICE pageable? If so
then I guess this could hang the system.

-----

These possibilities get complicated. It might be easier to do the
right thing (synchronization) than to imagine all the consequences of
doing the wrong thing. It's like lying. Once a lie is told it costs
additional supporting lies later on. The truth is often cheaper.




On Wed, 27 Dec 2006 15:56:55 -0500, BubbaGump <> wrote:

>Not have to worry too much? Yes, a race is unlikely but software
>should be designed without any race conditions except special
>situations where all possible outcomes of the race can be handled
>safely ("safely" being open to interpretation).
>
>In this situation, one of the possible outcomes is unsafe (could lead
>to an in-use resource being freed). The probability that it will
>happen is irrelevant.
>
>
>
>
>On Wed, 27 Dec 2006 10:07:30 -0800, "Doron Holan [MS]"
><doronh@nospam.microsoft.com> wrote:
>
>>IRP_MN_USAGE_NOTIFICATION is not tied to pnp state directly. you can tell
>>b/c as i indicated earlier, if another driver can the irp (which any driver
>>can), then it is not part of the pnp state machine maintained by the pnp
>>manager. fortunately, this irp is sent well before a q.r. can be sent so
>>you don't have to worry too much about synchronizing with q.r. ... as maxim
>>said, you do have to make sure that you are not power pagable anymore if you
>>succeed any of the usages.
>>
>>d

Doron
Thu Dec 28 13:33:14 CST 2006

the paging file and crash dump files are not true "files", you will not see
a create irp for them. as for query stop, you will need to pend i/o until
you get the cancel q.s. or the start irp again and then start processing
i/o. if a usage notification has already been sent and succeeded,fail the
q.s.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:r1r7p2pe3kdclue8dugsc3ml9acgf6pnhs@4ax.com...
>I do question the idea of safety in this situation. If
> IRP_MN_DEVICE_USAGE_NOTIFICATION was succeeded after
> IRP_MN_QUERY_REMOVE_DEVICE then wouldn't the paging, crash dump, or
> hibernation file still need to be opened on the device, and isn't
> opening a file on a device synchronized with
> IRP_MN_QUERY_REMOVE_DEVICE in Windows 2000 and later? Perhaps this is
> what Tim meant? I suppose IRP_MN_DEVICE_USAGE_NOTIFICATION in this
> situation is slightly redundant and would only prevent an error
> message that the file could not be opened from popping up later.
>
> That still leaves IRP_MN_QUERY_STOP_DEVICE. The OS doesn't
> synchronize IRP_MN_QUERY_STOP_DEVICE with file opens, does it? What
> if the device was stopped while being used for a paging file?
> IRP_MN_QUERY_STOP_DEVICE is only for resource re-balancing, so it
> would only temporarily stop paging, right? Is any of the OS code that
> sends IRP_MN_QUERY_STOP_DEVICE or IRP_MN_STOP_DEVICE pageable? If so
> then I guess this could hang the system.
>
> -----
>
> These possibilities get complicated. It might be easier to do the
> right thing (synchronization) than to imagine all the consequences of
> doing the wrong thing. It's like lying. Once a lie is told it costs
> additional supporting lies later on. The truth is often cheaper.
>
>
>
>
> On Wed, 27 Dec 2006 15:56:55 -0500, BubbaGump <> wrote:
>
>>Not have to worry too much? Yes, a race is unlikely but software
>>should be designed without any race conditions except special
>>situations where all possible outcomes of the race can be handled
>>safely ("safely" being open to interpretation).
>>
>>In this situation, one of the possible outcomes is unsafe (could lead
>>to an in-use resource being freed). The probability that it will
>>happen is irrelevant.
>>
>>
>>
>>
>>On Wed, 27 Dec 2006 10:07:30 -0800, "Doron Holan [MS]"
>><doronh@nospam.microsoft.com> wrote:
>>
>>>IRP_MN_USAGE_NOTIFICATION is not tied to pnp state directly. you can
>>>tell
>>>b/c as i indicated earlier, if another driver can the irp (which any
>>>driver
>>>can), then it is not part of the pnp state machine maintained by the pnp
>>>manager. fortunately, this irp is sent well before a q.r. can be sent so
>>>you don't have to worry too much about synchronizing with q.r. ... as
>>>maxim
>>>said, you do have to make sure that you are not power pagable anymore if
>>>you
>>>succeed any of the usages.
>>>
>>>d
>

BubbaGump
Thu Dec 28 22:31:25 CST 2006

I'm confused. This is a tangent purely for curiosity, but how can a
paging file not be a file? I thought my "c:\pagefile.sys" for
instance was my paging file.




On Thu, 28 Dec 2006 11:33:14 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>the paging file and crash dump files are not true "files", you will not see
>a create irp for them. as for query stop, you will need to pend i/o until
>you get the cancel q.s. or the start irp again and then start processing
>i/o. if a usage notification has already been sent and succeeded,fail the
>q.s.
>
>d

BubbaGump
Thu Dec 28 22:33:36 CST 2006

I agree with this. I was only mentioning query stop to play devil's
advocate.




On Thu, 28 Dec 2006 11:33:14 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>as for query stop, you will need to pend i/o until
>you get the cancel q.s. or the start irp again and then start processing
>i/o. if a usage notification has already been sent and succeeded,fail the
>q.s.

BubbaGump
Thu Dec 28 22:46:59 CST 2006

Basically what I'm saying is this.

A situation that seems almost impossible to have happen is a potential
problem that could be almost impossible to reproduce, and that means
that once it's buried in a mound of code it's almost impossible to
isolate and fix.

The world is now loaded with software from the normal computer kind to
what mp3 players or cable DVR boxes run. I get annoyed when I'm given
a piece of software and it hangs, glitches, or errors in some way
every so often in such a subtle way that I can't quite describe the
circumstances that cause it in order to report the bug. Add to that
the fact that I resent having to go through the effort of describing
in detail how to fix something that I paid for and should have worked
properly when I bought it. Add to that the fact that there often is
no where to report the bug.

You and me are the same person. You buy the same products as I do,
and we make the products that we buy from each other. If we build
unreliable products then we screw ourselves.

All I'm saying is for as many situations as possible, imagine the odd
or remote ways they might be used and make them work correctly when
you're writing the code. There are bound to be a few bugs later on
that were unforeseen, but that number can be greatly reduced if for
every potential bug we realize early on we fix.

Doron
Thu Dec 28 22:58:19 CST 2006

I meant that it is a file seen by the filesystem, not by you the driver.
the storage stack will never see the create irp (it does not see a create
for any file for that matter)

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:de69p2dkv1ccquf18u9mo09t9enddoqhqh@4ax.com...
> I'm confused. This is a tangent purely for curiosity, but how can a
> paging file not be a file? I thought my "c:\pagefile.sys" for
> instance was my paging file.
>
>
>
>
> On Thu, 28 Dec 2006 11:33:14 -0800, "Doron Holan [MS]"
> <doronh@nospam.microsoft.com> wrote:
>
>>the paging file and crash dump files are not true "files", you will not
>>see
>>a create irp for them. as for query stop, you will need to pend i/o until
>>you get the cancel q.s. or the start irp again and then start processing
>>i/o. if a usage notification has already been sent and succeeded,fail the
>>q.s.
>>
>>d
>