IRQL in DispatchReadWrite in higher-level Storage Filter Driver

[MKE...@il.ibm.com]

Hi,

We are developing a storage filter driver above the disk driver, to
intercept and back-up I/O.
Now I am slightly confused as to the IRQL at which we operate in the
DispatchReadWrite function.

Reading http://msdn.microsoft.com/en-us/library/ms794997.aspx (which I'd
like to believe), I am told that we are never above APC_LEVEL. This is
good for us, as we'd like to use an ERESOURCE. No mention here of
IRQL=DISPATCH_LEVEL for DispatchReadWrite.

But reading http://msdn.microsoft.com/en-us/library/ms810029.aspx (scroll
down to "Table 2 ..."), I see a worrying row
"DispatchRead and DispatchWrite routines of drivers in the storage stack:
IRQL <= DISPATCH_LEVEL".
But I see also a rows agreeing with the previous article:
"DispatchReadWrite (for devices not in paging path): PASSIVE_LEVEL"
"DispatchReadWrite (for devices in paging path): APC_LEVEL"
It is not clear to me how the three rows fit together. I might
optimistically believe that the row with DISPATCH_LEVEL applies only to
lower-level storage drivers.

Is that so? At our place in the storage stack, are we assured to be at
IRQL <= APC_LEVEL, as it says in the first article?

If yes, I have an additional question. Quoting again from the first
article:
"Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out)."
Indeed the documentation of KeWaitForSingleObject says that with non-zero
timeout, at APC_LEVEL, arbitrary thread context is not allowed. Is there
the same restriction with ExAcquireResourceSharedLite? The documentation
does not mention it, and AFAIK ERESOURCEs do not require the dispatcher
lock; on the other hand, it's clearly a blocking call.

Thank you very much,
Michael

[Maxim S. Shatskih]

> Reading http://msdn.microsoft.com/en-us/library/ms794997.aspx (which I'd
> like to believe), I am told that we are never above APC_LEVEL.

Doc error. This only occurs if the driver is called from the app.

Disk drivers can be called by the other drivers too.

> "DispatchRead and DispatchWrite routines of drivers in the storage stack:
> IRQL <= DISPATCH_LEVEL".

Correct.

--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com

[Don Burn]

See my response to your question on NTDEV. Please consider not posting on
multiple groups at least until you have given one group a chance to respond.

--
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

<MKE...@il.ibm.com> wrote in message
news:%23xZeODV$JHA....@TK2MSFTNGP05.phx.gbl...

> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4218 (20090705) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4218 (20090705) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[MKE...@il.ibm.com]

In my defense, this was a different Michael, albeit on the same project;
and I was not aware he asked a similar question on a different list.
But actually, his question was rather different - he did not ask whether
we could be called at DISPATCH_LEVEL, but rather if we could ignore calls
at APC_LEVEL.

Nevertheless, thanks for your answers, and I believe we now know what to
do.

Michael.