I am rather confused at the concept of arbitrary context which occurs
at high frequency in windows driver technical materials. Here are some
of my puzzles. Can anyone help to shed some lights?
Per my understanding, the context is only meaningful to a process
which, more specifically, usually means CR3 settings. But I not only see
“Arbitrary Process Context” but also see “Arbitrary Thread Context” and
sometimes it is just abbreviated as “Arbitrary Context”. I wonder which
is more exact and has a closer relation to windows driver development.
One frequently mentioned rule is that you cannot perform some actions
that may block, waiting for an object to be signaled for example,
because this will usually block the thread that is executing and because
there is not telling what thread will be blocked by you, it’s generally
not a good idea to do so. My question is, how can an arbitrary thread
run some actions that my driver is supposed to be completing? Shouldn’t
that my driver be executing at some system thread which compete for CPU
resource with all other threads? I would be grateful is some concrete
example can be given.
Another question which is not quite pertinent is: If thread
scheduling can only be done below DISPATCH level, then when a thread
which runs above DISPATCH level exit, how can it restart the thread
scheduler? I guess this cannot happen spontaneously without some trick,
right?
Thanks for your time and any help would be greatly appreciated.
----- Original Message -----
From: Wu, Cody
To: Windows System Software Devs Interest List
Sent: Sunday, September 24, 2006 4:30 PM
Subject: [ntdev] How to understand arbitrary context
Hi, All
I am rather confused at the concept of arbitrary context which occurs at high frequency in windows driver technical materials. Here are some of my puzzles. Can anyone help to shed some lights?
Per my understanding, the context is only meaningful to a process which, more specifically, usually means CR3 settings. But I not only see “Arbitrary Process Context” but also see “Arbitrary Thread Context” and sometimes it is just abbreviated as “Arbitrary Context”. I wonder which is more exact and has a closer relation to windows driver development.
One frequently mentioned rule is that you cannot perform some actions that may block, waiting for an object to be signaled for example, because this will usually block the thread that is executing and because there is not telling what thread will be blocked by you, it’s generally not a good idea to do so. My question is, how can an arbitrary thread run some actions that my driver is supposed to be completing? Shouldn’t that my driver be executing at some system thread which compete for CPU resource with all other threads? I would be grateful is some concrete example can be given.
Another question which is not quite pertinent is: If thread scheduling can only be done below DISPATCH level, then when a thread which runs above DISPATCH level exit, how can it restart the thread scheduler? I guess this cannot happen spontaneously without some trick, right?
Thanks for your time and any help would be greatly appreciated. J
“Wu, Cody” wrote in message news:xxxxx@ntdev… > 1) Per my understanding, the context is only meaningful to a process > which, more specifically, usually means CR3 settings. But I not only see > “Arbitrary Process Context” but also see “Arbitrary Thread Context” and > sometimes it is just abbreviated as “Arbitrary Context”. I wonder which > is more exact and has a closer relation to windows driver development.
The important thing here is not the name, but the fact that you are running on essentially any thread in the system and that you cannot rely on the user mode address space as it relates to a request. So for instance if you have not mapped a user mode buffer into kernel space you cannot in an arbitrary context safely access the buffer, since the user mode address may not be for the process that made the request.
> 2) One frequently mentioned rule is that you cannot perform some actions > that may block, waiting for an object to be signaled for example, > because this will usually block the thread that is executing and because > there is not telling what thread will be blocked by you, it’s generally > not a good idea to do so. My question is, how can an arbitrary thread > run some actions that my driver is supposed to be completing? Shouldn’t > that my driver be executing at some system thread which compete for CPU > resource with all other threads? I would be grateful is some concrete > example can be given.
Waiting in a thread by definition blocks the thread that is executing.
> 3) Another question which is not quite pertinent is: If thread > scheduling can only be done below DISPATCH level, then when a thread > which runs above DISPATCH level exit, how can it restart the thread > scheduler? I guess this cannot happen spontaneously without some trick, > right?
The only way thread scheduling occurs is by the scheduler running at DISPATCH_LEVEL and then the level dropping below DISPATCH_LEVEL. So if you are above DISPATCH_LEVEL either return from the ISR if this was due to an interrupt, or in the rare case where you did a KeRaiseIrql to that level, return to the level that is returned as the OldIrql value of that call.
If you are asking these questions, get you company to send you to a driver class.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com Remove StopSpam from the email to reply
> I am rather confused at the concept of arbitrary context which
occurs at high frequency in windows driver technical materials. Here
are some of my puzzles. Can anyone help to shed some lights?
Per my understanding, the context is only meaningful to a process
which, more specifically, usually means CR3 settings. But I not only
see “Arbitrary Process Context” but also see “Arbitrary Thread
Context” and sometimes it is just abbreviated as “Arbitrary
Context”. I wonder which is more exact and has a closer relation to
windows driver development.
The OS has interrupted some thread to run the code. I believe that
this would imply that you are at least at Dispatch level. Whatever
thread/process resources are currently available belong to an
arbitrary process/thread. In particular the 2/3GB of user address
space belongs to some arbitrary (read unknown or uncontrolled) so it
should not be accessed or otherwise disturbed.
One frequently mentioned rule is that you cannot perform some
actions that may block, waiting for an object to be signaled for
example, because this will usually block the thread that is
executing and because there is not telling what thread will be
blocked by you, it’s generally not a good idea to do so. My question
is, how can an arbitrary thread run some actions that my driver is
supposed to be completing? Shouldn’t that my driver be executing at
some system thread which compete for CPU resource with all other
threads? I would be grateful is some concrete example can be given.
You are generally running at dispatch level and the OS is waiting for
your return so that it can return control back to the current thread.
You are not allowed to block at dispatch level whether or not blocking
an unknown thread would be considered rude. Bad things will
happen (BSOD).
Another question which is not quite pertinent is: If thread
scheduling can only be done below DISPATCH level, then when a thread
which runs above DISPATCH level exit, how can it restart the thread
scheduler? I guess this cannot happen spontaneously without some
trick, right?
I don’t think that a thread can be exited at dispatch level. I have
never tried increasing IRQL to dispatch and then returning to a
calling thread without first lowering it. I assume bad things would
happen (others on this list could give a better answer. Maybe I’ll try
it to see what happens but I assume BSOD).
Thanks very much for your detailed explanations. I am beginning to
realize some of the intricacies involved. Though not totally clear of
the mystery, I will try to uncover the rest myself. Thanks again!
Best regards,
Cody
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert Newton
Sent: Monday, September 25, 2006 11:23 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to understand arbitrary context
I am rather confused at the concept of arbitrary context which
occurs at high frequency in windows driver technical materials. Here
are some of my puzzles. Can anyone help to shed some lights?
Per my understanding, the context is only meaningful to a process
which, more specifically, usually means CR3 settings. But I not only
see “Arbitrary Process Context” but also see “Arbitrary Thread
Context” and sometimes it is just abbreviated as “Arbitrary
Context”. I wonder which is more exact and has a closer relation to
windows driver development.
The OS has interrupted some thread to run the code. I believe that
this would imply that you are at least at Dispatch level. Whatever
thread/process resources are currently available belong to an
arbitrary process/thread. In particular the 2/3GB of user address
space belongs to some arbitrary (read unknown or uncontrolled) so it
should not be accessed or otherwise disturbed.
One frequently mentioned rule is that you cannot perform some
actions that may block, waiting for an object to be signaled for
example, because this will usually block the thread that is
executing and because there is not telling what thread will be
blocked by you, it’s generally not a good idea to do so. My question
is, how can an arbitrary thread run some actions that my driver is
supposed to be completing? Shouldn’t that my driver be executing at
some system thread which compete for CPU resource with all other
threads? I would be grateful is some concrete example can be given.
You are generally running at dispatch level and the OS is waiting for
your return so that it can return control back to the current thread.
You are not allowed to block at dispatch level whether or not blocking
an unknown thread would be considered rude. Bad things will
happen (BSOD).
Another question which is not quite pertinent is: If thread
scheduling can only be done below DISPATCH level, then when a thread
which runs above DISPATCH level exit, how can it restart the thread
scheduler? I guess this cannot happen spontaneously without some
trick, right?
I don’t think that a thread can be exited at dispatch level. I have
never tried increasing IRQL to dispatch and then returning to a
calling thread without first lowering it. I assume bad things would
happen (others on this list could give a better answer. Maybe I’ll try
it to see what happens but I assume BSOD).
I read it carefully. That’s great stuff for beginners. Thanks a lot!
Best regards,
Cody
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Sunday, September 24, 2006 9:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to understand arbitrary context
To: Windows System Software Devs Interest List mailto:xxxxx
Sent: Sunday, September 24, 2006 4:30 PM
Subject: [ntdev] How to understand arbitrary context
Hi, All
I am rather confused at the concept of arbitrary context which occurs at high frequency in windows driver technical materials. Here are some of my puzzles. Can anyone help to shed some lights?
1) Per my understanding, the context is only meaningful to a process which, more specifically, usually means CR3 settings. But I not only see “Arbitrary Process Context” but also see “Arbitrary Thread Context” and sometimes it is just abbreviated as “Arbitrary Context”. I wonder which is more exact and has a closer relation to windows driver development.
2) One frequently mentioned rule is that you cannot perform some actions that may block, waiting for an object to be signaled for example, because this will usually block the thread that is executing and because there is not telling what thread will be blocked by you, it’s generally not a good idea to do so. My question is, how can an arbitrary thread run some actions that my driver is supposed to be completing? Shouldn’t that my driver be executing at some system thread which compete for CPU resource with all other threads? I would be grateful is some concrete example can be given.
3) Another question which is not quite pertinent is: If thread scheduling can only be done below DISPATCH level, then when a thread which runs above DISPATCH level exit, how can it restart the thread scheduler? I guess this cannot happen spontaneously without some trick, right?
Thanks for your time and any help would be greatly appreciated.
> I am rather confused at the concept of arbitrary context which occurs
at high frequency in windows driver technical materials.
This just means - “thread/process context is not known”.
sometimes it is just abbreviated as “Arbitrary Context”. I wonder which
is more exact and has a closer relation to windows driver development.
All of them are exact. If some code is named to be executed “in arbitrary
context”, this means - you cannot assume anything about the current process and
the current thread in this code. In fact, the notion of the “current thread” is
just not working for such a code.
not a good idea to do so. My question is, how can an arbitrary thread
run some actions that my driver is supposed to be completing?
Arbitrary thread context is usually DISPATCH_LEVEL, and you cannot wait on
DISPATCH.
scheduling can only be done below DISPATCH level, then when a thread
which runs above DISPATCH level exit
I don’t think that PsTerminateSystemThread can be called on DISPATCH.
