The DDK documentation explains little on the two terms. I consulted
Walter Oney's book, and got some tips. I post my premature
understanding here and hope experts to correct my errors or give me
some comments.

To my understanding,

1) If thread A sends IRP_MJ_CREATE to driver X, and next, sends
IRP_MJ_XXX to driver X's corresponding dispatch routine, then, the
dispatch routine is being executed in a "nonarbitrary thread context".

2) If thread A sends IRP_MJ_CREATE to driver X, and next, another
thread, say thread B, sends IRP_MJ_XXX to driver X's corresponding
dispatch routine, then, the dispatch routine is being executed in an
"arbitrary thread context".

3) For a given dispatch routine, DDK (or Microsoft) specifies whether
it must be called in a "nonarbitrary thread context" or in an
"arbitrary thread context" (with some exceptions, see DDK
documentation : "Dispatch Routine IRQL and Thread Context")

Is my understanding correct?

Any comments will be helpful. Thanks.

"xmllmx" <xmllmx@gmail.com> wrote in message
news:1187451094.631291.7410@m37g2000prh.googlegrou ps.com...

Multiple threads can open a handle on a device and multiple threads can
make calls to various calls to the driver.

For those listed as "non-arbitrary", the context will be the context of the
caller intil the call returns. For example, when thread A makes a call to
Read, Write or DeviceIoControl the driver is called in the context of thread
A. Same for thread B (or C, or...).

IOW, the concept of "arbitrary" and "non-arbitrary" applies from the point
the IRP_MJ_XYZ handler is entered until the point where it returns.


your driver, then the documentation is describing the behavior of the I/O
manager is. For example, the documentation is telling the driver writer that
"If a user-mode application does a Read on a device, then the I/O manager
will call your driver at IRP_MJ_READ in the non-arbitrary context of the
user-mode applications thread".

Hope this helps.

Thomas F. Divine

"Arbitrary thread context" means a DPC or even ISR, where you can assume
nothing about what is the current thread. The notion of "current thread" is
just plain invalid in DPCs and calls made by DPCs (completion routines,
ClientEventXxx in TDI, ProtocolReceive(Packet) and so on).

Work items, generally speaking, are also arbitrary thread, but all these
threads belong to System process, that's why the term "system thread context"
is more often used for them.

DriverEntry and MJ_PNP paths are also called from system thread context -
i.e. some unknown thread, and it is only known it is in the System process.

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

"xmllmx" <xmllmx@gmail.com> wrote in message
news:1187451094.631291.7410@m37g2000prh.googlegrou ps.com...

Thomas & Maxim,

Thank you very much for correcting my errors.