irql

Hello, I have observation with another driver in the system and want
some other opinions.

Basically if have code like so in my Write Dispatch routine of my
storage filter

if ( KeGetCurrentIrql() >= DISPATCH_LEVEL ) {

DbgBreakPoint();

}

printing the result of the call prints 2, which is expected. However
doing !irql in the debugger shows it as 0 for both proc 0 and 1. I only
see this when the process is the idle process. In this particular case
the stack is

driver!DriverTimerDpc

nt!KiTimerExpiration+0x255 (FPO: [EBP 0x8056f5e0] [4,36,0])

nt!KiRetireDpcList+0x63

In particular, the DriverTimerDpc is issuing a write request and I think
it is DISPATCH_LEVEL. However hitting go works fine.

My question is

Is ‘Driver’ incorrect in that it is sending a request at DISPATCH_LEVEL
or am I incorrect in assuming that my Write Dispatch can not be called
at DL? (I know it can be called at APC)

According to the docs I think I am right:

Most drivers’ dispatch routines are called in an arbitrary thread
context at IRQL = PASSIVE_LEVEL, with the following exceptions:

* Any highest-level driver’s dispatch routines are called in the
context of the thread that originated the I/O request, which is commonly
a user-mode application thread.

In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL = PASSIVE_LEVEL.

* The DispatchRead, DispatchWrite, and DispatchDeviceControl
routines of lowest-level device drivers, and of intermediate drivers
layered above them in the system paging path, can be called at IRQL =
APC_LEVEL and in an arbitrary thread context.

The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out).

* The DispatchPower routine of drivers in the hibernation and/or
paging paths can be called at IRQL DISPATCH_LEVEL. The DispatchPnP
routines of such drivers must be prepared to handle PnP
IRP_MN_DEVICE_USAGE_NOTIFICATION
mk:htm> requests.
* The DispatchPower routine of drivers that require inrush power
at start-up can be called at IRQL DISPATCH_LEVEL.

Thanks,

Rob</mk:>

Again, minus the html.

sorry,
Rob

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:27 PM
To: NT Developers Interest List (xxxxx@lists.osr.com)
Subject: irql

Hello, I have observation with another driver in the system and want
some other opinions.
?
Basically if have code like so in my Write Dispatch routine of my
storage filter
??? if ( KeGetCurrentIrql() >= DISPATCH_LEVEL ) {
??? DbgBreakPoint();
??? }
?
printing the result of the call prints 2, which is expected.? However
doing !irql in the debugger shows it as 0 for both proc 0 and 1.? I only
see this when the process is the idle process.? In this particular case
the stack is
?
driver!DriverTimerDpc
nt!KiTimerExpiration+0x255 (FPO: [EBP 0x8056f5e0] [4,36,0])
nt!KiRetireDpcList+0x63
?
In particular, the DriverTimerDpc is issuing a write request and I think
it is DISPATCH_LEVEL.? However hitting go works fine.
?
My question is
Is ?Driver? incorrect in that it is sending a request at DISPATCH_LEVEL
or am I incorrect in assuming that my Write Dispatch can not be called
at DL? (I know it can be called at APC)
?
According to the docs I think I am right:
Most drivers? dispatch routines are called in an arbitrary thread
context at IRQL = PASSIVE_LEVEL, with the following exceptions:
? Any highest-level driver?s dispatch routines are called in the context
of the thread that originated the I/O request, which is commonly a
user-mode application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL = PASSIVE_LEVEL.
? The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and in
an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver?s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out).
? The DispatchPower routine of drivers in the hibernation and/or paging
paths can be called at IRQL DISPATCH_LEVEL. The DispatchPnP routines of
such drivers must be prepared to handle PnP
IRP_MN_DEVICE_USAGE_NOTIFICATION requests.
? The DispatchPower routine of drivers that require inrush power at
start-up can be called at IRQL DISPATCH_LEVEL.
?
?
Thanks,
Rob
?

The DDK is not being entirely accurate. The storage stack, for example, will
issue read and write requests at DISPATCH_LEVEL.

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:40 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: irql

Again, minus the html.

sorry,
Rob

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:27 PM
To: NT Developers Interest List (xxxxx@lists.osr.com)
Subject: irql

Hello, I have observation with another driver in the system and want some
other opinions.
?
Basically if have code like so in my Write Dispatch routine of my storage
filter
??? if ( KeGetCurrentIrql() >= DISPATCH_LEVEL ) {
??? DbgBreakPoint();
??? }
?
printing the result of the call prints 2, which is expected.? However doing
!irql in the debugger shows it as 0 for both proc 0 and 1.? I only see this
when the process is the idle process.? In this particular case the stack is
?
driver!DriverTimerDpc
nt!KiTimerExpiration+0x255 (FPO: [EBP 0x8056f5e0] [4,36,0])
nt!KiRetireDpcList+0x63
?
In particular, the DriverTimerDpc is issuing a write request and I think it
is DISPATCH_LEVEL.? However hitting go works fine.
?
My question is
Is ‘Driver’ incorrect in that it is sending a request at DISPATCH_LEVEL or
am I incorrect in assuming that my Write Dispatch can not be called at DL?
(I know it can be called at APC)
?
According to the docs I think I am right:
Most drivers’ dispatch routines are called in an arbitrary thread context at
IRQL = PASSIVE_LEVEL, with the following exceptions:
* Any highest-level driver’s dispatch routines are called in the context of
the thread that originated the I/O request, which is commonly a user-mode
application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at IRQL =
PASSIVE_LEVEL.
* The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above them
in the system paging path, can be called at IRQL = APC_LEVEL and in an
arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine that
also processes read and/or write requests in such a lowest-level device or
intermediate driver, must be resident at all times. These driver routines
can neither be pageable nor be part of a driver’s pageable-image section;
they must not access any pageable memory. Furthermore, they should not be
dependent on any blocking calls (such as KeWaitForSingleObject with a
nonzero time-out).
* The DispatchPower routine of drivers in the hibernation and/or paging
paths can be called at IRQL DISPATCH_LEVEL. The DispatchPnP routines of such
drivers must be prepared to handle PnP IRP_MN_DEVICE_USAGE_NOTIFICATION
requests.
* The DispatchPower routine of drivers that require inrush power at start-up
can be called at IRQL DISPATCH_LEVEL.
?
?
Thanks,
Rob
?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

In what situations? I have yet to come across any valid cases of
this, even on storage drivers that are running on +1 mil systems.

Keep in mind I am a storage class filter layered as an UpperFilter of
the volume class.

Thanks,
Rob

The DDK is not being entirely accurate. The storage stack, for
example,
will
issue read and write requests at DISPATCH_LEVEL.

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:40 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: irql

Again, minus the html.

sorry,
Rob

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:27 PM
To: NT Developers Interest List (xxxxx@lists.osr.com)
Subject: irql

Hello, I have observation with another driver in the system and want
some
other opinions.

Basically if have code like so in my Write Dispatch routine of my
storage
filter
??? if ( KeGetCurrentIrql() >= DISPATCH_LEVEL ) {
??? DbgBreakPoint();
??? }

printing the result of the call prints 2, which is expected.? However
doing
!irql in the debugger shows it as 0 for both proc 0 and 1.? I only see
this
when the process is the idle process.? In this particular case the
stack
is

driver!DriverTimerDpc
nt!KiTimerExpiration+0x255 (FPO: [EBP 0x8056f5e0] [4,36,0])
nt!KiRetireDpcList+0x63

In particular, the DriverTimerDpc is issuing a write request and I
think
it
is DISPATCH_LEVEL.? However hitting go works fine.

My question is
Is ‘Driver’ incorrect in that it is sending a request at
DISPATCH_LEVEL or
am I incorrect in assuming that my Write Dispatch can not be called at
DL?
(I know it can be called at APC)

According to the docs I think I am right:
Most drivers’ dispatch routines are called in an arbitrary thread
context
at
IRQL = PASSIVE_LEVEL, with the following exceptions:
* Any highest-level driver’s dispatch routines are called in the
context
of
the thread that originated the I/O request, which is commonly a
user-mode
application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL

PASSIVE_LEVEL.
* The DispatchRead, DispatchWrite, and DispatchDeviceControl routines
of
lowest-level device drivers, and of intermediate drivers layered above
them
in the system paging path, can be called at IRQL = APC_LEVEL and in an
arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that
also processes read and/or write requests in such a lowest-level
device or
intermediate driver, must be resident at all times. These driver
routines
can neither be pageable nor be part of a driver’s pageable-image
section;
they must not access any pageable memory. Furthermore, they should not
be
dependent on any blocking calls (such as KeWaitForSingleObject with a
nonzero time-out).
* The DispatchPower routine of drivers in the hibernation and/or
paging
paths can be called at IRQL DISPATCH_LEVEL. The DispatchPnP routines
of
such
drivers must be prepared to handle PnP
IRP_MN_DEVICE_USAGE_NOTIFICATION
requests.
* The DispatchPower routine of drivers that require inrush power at
start-
up
can be called at IRQL DISPATCH_LEVEL.

Thanks,
Rob


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cdp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You will only see this behavior below the disk class driver.

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Tuesday, August 26, 2003 12:09 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: irql

In what situations? I have yet to come across any valid cases of this,
even on storage drivers that are running on +1 mil systems.

Keep in mind I am a storage class filter layered as an UpperFilter of the
volume class.

Thanks,
Rob

The DDK is not being entirely accurate. The storage stack, for
example,
will
issue read and write requests at DISPATCH_LEVEL.

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:40 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: irql

Again, minus the html.

sorry,
Rob

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:27 PM
To: NT Developers Interest List (xxxxx@lists.osr.com)
Subject: irql

Hello, I have observation with another driver in the system and want
some
other opinions.

Basically if have code like so in my Write Dispatch routine of my
storage
filter
??? if ( KeGetCurrentIrql() >= DISPATCH_LEVEL ) {
??? DbgBreakPoint();
??? }

printing the result of the call prints 2, which is expected.? However
doing !irql in the debugger shows it as 0 for both proc 0 and 1.? I
only see this
when the process is the idle process.? In this particular case the
stack
is

driver!DriverTimerDpc
nt!KiTimerExpiration+0x255 (FPO: [EBP 0x8056f5e0] [4,36,0])
nt!KiRetireDpcList+0x63

In particular, the DriverTimerDpc is issuing a write request and I
think
it
is DISPATCH_LEVEL.? However hitting go works fine.

My question is
Is ‘Driver’ incorrect in that it is sending a request at
DISPATCH_LEVEL or
am I incorrect in assuming that my Write Dispatch can not be called at
DL?
(I know it can be called at APC)

According to the docs I think I am right:
Most drivers’ dispatch routines are called in an arbitrary thread
context
at
IRQL = PASSIVE_LEVEL, with the following exceptions:
* Any highest-level driver’s dispatch routines are called in the
context
of
the thread that originated the I/O request, which is commonly a
user-mode
application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL

PASSIVE_LEVEL.
* The DispatchRead, DispatchWrite, and DispatchDeviceControl routines
of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and
in an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that
also processes read and/or write requests in such a lowest-level
device or
intermediate driver, must be resident at all times. These driver
routines
can neither be pageable nor be part of a driver’s pageable-image
section;
they must not access any pageable memory. Furthermore, they should not
be
dependent on any blocking calls (such as KeWaitForSingleObject with a
nonzero time-out).
* The DispatchPower routine of drivers in the hibernation and/or
paging
paths can be called at IRQL DISPATCH_LEVEL. The DispatchPnP routines
of
such
drivers must be prepared to handle PnP
IRP_MN_DEVICE_USAGE_NOTIFICATION
requests.
* The DispatchPower routine of drivers that require inrush power at
start-
up
can be called at IRQL DISPATCH_LEVEL.

Thanks,
Rob


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cdp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

!irql currently only produces useful results on a crashdump, not a live
system. Please don’t depend on it. (I’ve already complained about this to
the debugger guys. They took me more or less seriously and they are
thinking about how to fix it.)


Jake Oshins
Windows Base Kernel Team

This posting is provided “AS IS” with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add “Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

“Rob Green” wrote in message news:xxxxx@ntdev…

Again, minus the html.

sorry,
Rob

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, August 25, 2003 5:27 PM
To: NT Developers Interest List (xxxxx@lists.osr.com)
Subject: irql

Hello, I have observation with another driver in the system and want
some other opinions.

Basically if have code like so in my Write Dispatch routine of my
storage filter
if ( KeGetCurrentIrql() >= DISPATCH_LEVEL ) {
DbgBreakPoint();
}

printing the result of the call prints 2, which is expected. However
doing !irql in the debugger shows it as 0 for both proc 0 and 1. I only
see this when the process is the idle process. In this particular case
the stack is

driver!DriverTimerDpc
nt!KiTimerExpiration+0x255 (FPO: [EBP 0x8056f5e0] [4,36,0])
nt!KiRetireDpcList+0x63

In particular, the DriverTimerDpc is issuing a write request and I think
it is DISPATCH_LEVEL. However hitting go works fine.

My question is
Is ‘Driver’ incorrect in that it is sending a request at DISPATCH_LEVEL
or am I incorrect in assuming that my Write Dispatch can not be called
at DL? (I know it can be called at APC)

According to the docs I think I am right:
Most drivers’ dispatch routines are called in an arbitrary thread
context at IRQL = PASSIVE_LEVEL, with the following exceptions:
. Any highest-level driver’s dispatch routines are called in the context
of the thread that originated the I/O request, which is commonly a
user-mode application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL = PASSIVE_LEVEL.
. The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and in
an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out).
. The DispatchPower routine of drivers in the hibernation and/or paging
paths can be called at IRQL DISPATCH_LEVEL. The DispatchPnP routines of
such drivers must be prepared to handle PnP
IRP_MN_DEVICE_USAGE_NOTIFICATION requests.
. The DispatchPower routine of drivers that require inrush power at
start-up can be called at IRQL DISPATCH_LEVEL.

Thanks,
Rob

I use !pcr.

Jake Oshins wrote:

!irql currently only produces useful results on a crashdump, not a live
system.


If replying by e-mail, please remove “nospam.” from the address.

James Antognini
Windows DDK MVP

This ought to be consolidated into an NTDEV FAQ. Any volunteer?

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Wednesday, August 27, 2003 6:40 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: irql

I use !pcr.

Jake Oshins wrote:

!irql currently only produces useful results on a crashdump, not a
live system.


If replying by e-mail, please remove “nospam.” from the address.

James Antognini
Windows DDK MVP


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
>
> This ought to be consolidated into an NTDEV FAQ. Any volunteer?
>
>

Sigh! Someone here at OSR will do it…

p