JustKernel

Most Windows drivers do not cr eate threads; instead , a driver consists of a group of routines that are called in an existing thread that was created by an application or system component.

Kernel-mode software developers use the term “thread context” in two slightly different ways. In its narrowest meaning, thread context is the value of the thread’s CONTEXT structure. The CONTEXT structure contains the values of the hardware registers, the stacks and the thread’s private storage areas. The exact contents and layout of this structure will vary according to the hardware platform. When Windows schedules a user thread, it loads information from the thread’s CONTEXT structure into the user-mode address space.

From a driver developer’s perspective, however , “thread context” has a broader meaning. For a driver, the thread context includes not only the values stored in the CONTEXT structure, but also the operating environment they define – particularly, the security rights of the calling application. For  eg, a driver routine might be called in the context of a user-mode application, but it can in turn call a ZwXxx routine to perform an operation in the context of the operating system kernel.

The thread context in which driver routines are called depends on the type of the device, on the driver’s position in the device stack, and on the other activities currently in progress on the system. When a driver routine is called to perform I/O operation, the thread context might contain the user-mode address space and security rights of th eprocess that requested the I/O. However, if the calling process was performing an operation on behalf of another user or application, the thread context might contain the user-mode address space an security rights of a drifferent process. In other words, the user-mode address space might contain information that pertains to the process that requested the I/O or it might insteead contain tinformation that pertains to a different process.

The dispatch routines of the file system drivers (FSDs) , file system (FS) filter drivers, and other hightest level drivers normall receive I/O requests in the context of the thread that initiated the request.

Most other routines int ht FSDs, FS filters and highest level drivers- and most routines in lowerp-level drivers – are called in tan arbitrary thread context. Although the highest-level drivers receive I/O requests in the context of the requesting thread, they often forward those requests to their lower level drivers on different threads. Consequently , you can make no assumptions about the contents of the user-mode address spacet at the time such routnes ar called.

For. eg. , when a user-mode application request  a synchronous I/O operation, the highest -level driver’s I/O dispatch routine is called in the context of thre thread that requested the ooperation. The dispath routines queues the I/O request for processing by lowe-level drivers. The requesting thread then enters a wait state until the I/O is complete. A different thread de-queues the request, which is handled b lower-level drivers that run in the context of whatever thread happens to be executing at the time they are called.

Originally Posted On: 2010-04-17 02:59:07

Anshul Makkar, anshul_makkar@justkernel.com

Tags: Thread Context