ZwXxx at IRQL > PASIVE_LEVEL ?
Eric Jobidon
Hi all,
I am writing a low-level device driver for NT 4.0 and am having problems
using the ZwXxx set of functions. The DDK tells me that the functions
should be running at IRQL PASIVE_LEVEL (if I understand correctly, this
means they shouldn`t be called at IRQL DISPATCH_LEVEL or DIRQL). My first
question is quite simple: Why? (I wish the answer could be
as simple!)
My second question relates to the use of these functions in my driver`s
DispatchRoutine. I need to invoke ZwReadFile from within a dispatch routine
and I always get an error message stating that my HANDLE is invalid. On the
other hand, if I try to use the same piece of code in the DriverEntry or
DriverUnLoad functions, everything works perfectly... What is going on? I
tried the same code in a StartIo function but I still get the same
error...
What am I doing wrong?
The sample source code in the DDK doesn`t seem to cover that situation. The
only hint I got was to start a separate thread to handle those requests in
PASSIVE_LEVEL. Would that solve my problem? if so, why?
Thank you sooooo much!
Eric
Jamey Kirby
The ZwXxx routines require that you be running in passive level. That
is why you are getting the bug check. The second problem relating to
the handles is because the process that opened the file isn't the one
using the handle. The solution to both of these problems is to use a
system thread to process IRPs. While in the system thread, the system
process will be the active process. This will guarantee that you are
running at passive level and that the file handles will be valid. You
must make sure that the file is opened in the context of the system
process.
Hope this helps.
Jamey Kirby
Senior Partner
Magnuson, Kirby & Associates, LLC.
jki...@gloryroad.netX
Robert W. Fuller
Eric Jobidon wrote:
> I am writing a low-level device driver for NT 4.0 and am having problems
> using the ZwXxx set of functions. The DDK tells me that the functions
> should be running at IRQL PASIVE_LEVEL (if I understand correctly, this
> means they shouldn`t be called at IRQL DISPATCH_LEVEL or DIRQL). My first
> question is quite simple: Why? (I wish the answer could be
> as simple!)
Page faults are fatal at raised IRQL. At DISPATCH_LEVEL or above, a
driver may only access non paged pool. From an operating system design
point of view, there're very good reasons for this, although they are
beyond the scope of this post.
> My second question relates to the use of these functions in my driver`s
> DispatchRoutine. I need to invoke ZwReadFile from within a dispatch routine
> and I always get an error message stating that my HANDLE is invalid. On the
> other hand, if I try to use the same piece of code in the DriverEntry or
> DriverUnLoad functions, everything works perfectly... What is going on? I
> tried the same code in a StartIo function but I still get the same
> error...
> What am I doing wrong?
You must observe restrictions regarding process context. A handle is
only valid within the context of the process that created the handle.
The IO Manager calls your DriverEntry() and DriverUnload() routines in
the context of the "System" process, which you can see in Task Manager
under the "Processes" tab.
> The sample source code in the DDK doesn`t seem to cover that situation. The
> only hint I got was to start a separate thread to handle those requests in
> PASSIVE_LEVEL. Would that solve my problem? if so, why?
> Thank you sooooo much!
PsCreateSystemThread() allows a device driver to create a worker thread
in the System process context by specifying a NULL handle for the
Process parameter. Therefore, your DriverEntry() and DriverUnload()
routines, as well as your worker threads created with
PsCreateSystemThread() could share the same handles. DriverEntry(),
DriverUnload(), and your worker threads all run at PASSIVE_LEVEL unless
they call a function which raises their IRQL.
Robert W. Fuller
Software Engineer
Mark A. Overby
Because:
1. Some of those routines invoke code that is paged.
2. Some of them do nasty things when run in an arbitrary thread context
3. Some of them call drivers who expect to be calling at PASSIVE
The list goes on and on.
HANDLES are process specific. If you open a handle in your DriverEntry,
you're in thread context A. Then when some user mode app calls you, you're
in thread context B. The handle is not longer valid.
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation
