Windows Kernel-Mode Process and Thread Manager

A process is a software program that is currently running in Windows. Every process has an ID, a number that identifies it. A thread is an object that identifies which part of the program is running. Each thread has an ID, a number that identifies it.

A process may have more than one thread. The purpose of a thread is to allocate processor time. On a machine with one processor, more than one thread can be allocated, but only one thread can run at a time. Each thread only runs a short time and then the execution is passed on to the next thread, giving the user the illusion that more than one thing is happening at once. On a machine with more than one processor, true multi-threading can take place. If an application has multiple threads, the threads can run simultaneously on different processors.

The Windows kernel-mode process and thread manager handles the execution of all threads in a process. Whether you have one processor or more, great care must be taken in driver programming to make sure that all threads of your process are designed so that no matter what order the threads are handled, your driver will operate properly.

If threads from different processes attempt to use the same resource at the same time, problems can occur. Windows provides several techniques to avoid this problem. The technique of making sure that threads from different processes do not touch the same resource is called synchronization. For more information about synchronization, see Synchronization Techniques.

Routines that provide a direct interface to the process and thread manager are usually prefixed with the letters «Ps«; for example, PsCreateSystemThread. For a list of kernel DDIs, see Windows kernel.

This set of guidelines applies to these callback routines:

• Keep routines short and simple.
• Do not make calls into a user mode service to validate the process, thread, or image.
• Do not make registry calls.
• Do not make blocking and/or Interprocess Communication (IPC) function calls.
• Do not synchronize with other threads because it can lead to reentrancy deadlocks.
• Use System Worker Threads to queue work especially work involving:
  • Slow API’s or API’s that call into other process.
  • Any blocking behavior which could interrupt threads in core services.
• If you use System Worker Threads do not wait on the work to complete. Doing so defeats the purpose of queuing the work to be completed asynchronously.
• Be considerate of best practices for kernel mode stack usage. For examples, see How do I keep my driver from running out of kernel-mode stack? and Key Driver Concepts and Tips.

Subsystem Processes

Starting in WindowsВ 10, the Windows Subsystem for Linux (WSL) enables a user to run native Linux ELF64 binaries on Windows, alongside other Windows applications. For information about WSL architecture and the user-mode and kernel-mode components that are required to run the binaries, see the posts on the Windows Subsystem for Linux blog.

One of the components is a subsystem process that hosts the unmodified user-mode Linux binary, such as /bin/bash. Subsystem processes do not contain data structures associated with Win32 processes, such as Process Environment Block (PEB) and Thread Environment Block (TEB). For a subsystem process, system calls and user mode exceptions are dispatched to a paired driver.

Here are the changes to the Process and Thread Manager Routines in order to support subsystem processes:

• The WSL type is indicated by the SubsystemInformationTypeWSL value in the SUBSYSTEM_INFORMATION_TYPE enumeration. Drivers can call NtQueryInformationProcess and NtQueryInformationThread to determine the underlying subsystem. Those calls return SubsystemInformationTypeWSL for WSL.
• Other kernel mode drivers can get notified about subsystem process creation/deletion by registering their callback routine through the PsSetCreateProcessNotifyRoutineEx2 call. To get notifications about thread creation/deletion, drivers can call PsSetCreateThreadNotifyRoutineEx, and specify PsCreateThreadNotifySubsystems as the type of notification.
• The PS_CREATE_NOTIFY_INFO structure has been extended to include a IsSubsystemProcess member that indicates a subsystem other than Win32. Other members such as FileObject, ImageFileName, CommandLine indicate additional information about the subsystem process. For information about the behavior of those members, see SUBSYSTEM_INFORMATION_TYPE.

—>

Kernel-Mode Driver Architecture Design Guide

For information about programming interfaces that your driver can implement or call, see the Kernel-Mode Driver Reference.

This section includes general concepts to help you understand kernel-mode programming and describes specific techniques of kernel programming. For a general overview of Windows Drivers, see Getting Started with Windows Drivers, which provides a general overview of Windows components, lists the types of device drivers used in Windows, discusses the goals of Windows device drivers, and discusses generic sample device drivers included in the kit.

This section contains conceptual information that describes and helps you build kernel-mode drivers.

An Overview containing:

Kernel-Mode Components describes the primary kernel-mode managers and components of the Windows operating system.

Component	Description
Managers
Windows Kernel-Mode Object Manager	Manages objects: files, devices, synchronization mechanisms, registry keys, and so on.
Windows Kernel-Mode Memory Manager	Manages physical memory for the operating system.
Windows Kernel-Mode Process and Thread Manager	Handles the execution of all threads in a process.
Windows Kernel-Mode I/O Manager	Manages the communication between applications and the interfaces provided by device drivers.
Windows Kernel-Mode Plug and Play Manager	A subsystem of the I/O manager, the Plug and Play (PnP) Manager enables a PC to recognize when a device is added to the system.
Windows Kernel-Mode Power Manager	Manages the orderly change in power status for all devices that support power state changes.
Windows Kernel-Mode Configuration Manager	Manages the registry, such as monitoring changes in the registry or registering callbacks on specific registry data.
Windows Kernel-Mode Kernel Transaction Manager	Implements transaction processing in kernel mode.
Windows Kernel-Mode Security Reference Monitor	Provides routines for your driver to work with access control.
Libraries
Windows Kernel-Mode Kernel Library	Implements the core functionality that everything else in the operating system depends upon. The Microsoft Windows kernel provides basic low-level operations such as scheduling threads or routing hardware interrupts.
Windows Kernel-Mode Executive Support Library	Refers to kernel-mode components that provide a variety of services to device drivers, including: object management, memory management, process and thread management, input/output management, and configuration management.
Windows Kernel-Mode Run-Time Library	A set of common utility routines needed by various kernel-mode components.
Windows Kernel-Mode Safe String Library	A safe string library to provide greater security in kernel-mode development.
Windows Kernel-Mode DMA Library	A direct memory access (DMA) library for device driver developers.
Windows Kernel-Mode HAL Library	A hardware abstraction layer (HAL) for kernel-mode driver development.
Windows Kernel-Mode CLFS Library	A transactional logging system, the Common Log File System (CLFS).
Windows Kernel-Mode WMI Library	A general mechanism for managing components, called Windows Management Instrumentation (WMI).

Writing WDM Drivers and Introduction to WDM provide information needed to write drivers using the Windows Driver Model (WDM).

Device Objects and the other topics in Device Objects and Device Stacks describe how the operating system represents devices by device objects.

Memory Management for Windows Drivers illustrates how kernel-mode drivers allocate memory for purposes such as storing internal data, buffering data during I/O operations, and sharing memory with other kernel-mode and user-mode components.

Security From Controlling Device Access and Privileges to SDDL for Device objects, ensure that your drivers are as secure as possible.

Handling IRPs describes how kernel-mode drivers handle I/O request packets (IRPs).

DMA Direct Memory Access (DMA) is a critical aspect of driver development, and the topics in this node cover DMA from A to Z.

Controller Objects represent a physical device controller with attached devices.

Interrupt Service Routines (ISRs) handle interrupts for drivers of a physical device that receives interrupts.

Message-Signaled Interrupts trigger an interrupt by writing a value to a particular memory address.

Deferred Procedure Calls (DPC Objects) can be queued from ISRs and are executed at a later time and at a lower IRQL than the ISR.

Plug and Play (PnP) focuses on the system software support for PnP and how drivers use that support to implement PnP.

Power Management describes the architecture that provides a comprehensive approach to system and device power management.

Windows Management Instrumentation (WMI) are extensions to your kernel-mode driver, which enable your driver to become a WMI provider. A WMI provider makes measurement and instrumentation data available to WMI consumers, such as user-mode applications.

Driver Programming Techniques Programming drivers in the kernel mode of Windows requires techniques that sometimes differ significantly from those of ordinary user-mode programming.

Windows Kernel-Mode Object Manager

The Windows kernel-mode object manager component manages objects. Files, devices, synchronization mechanisms, registry keys, and so on, are all represented as objects in kernel mode. Each object has a header (containing information about the object such as its name, type, and location), and a body (containing data in a format determined by each type of object).

Windows has more than 25 types of objects. A few of the types are:

The object manager manages the objects in Windows by performing the following major tasks:

Managing the creation and destruction of objects.

Keeping an object namespace database for tracking object information.

Keeping track of resources assigned to each process.

Tracking access rights for specific objects to provide security.

Managing the lifetime of an object and determining when an object will be automatically destroyed to recycle resource space.

For more information about objects in Windows, see Managing Kernel Objects.

Routines that provide a direct interface to the object manager are usually prefixed with the letters «Ob«; for example, ObGetObjectSecurity. For a list of object manager routines, see Object Manager Routines.

Note that Windows uses objects as an abstraction for resources. However, Windows is not object-oriented in the classical C++ meaning of the term. Windows is object-based. For more information on what object-based means for Windows, see Object-Based.

User mode and kernel mode

A processor in a computer running Windows has two different modes: user mode and kernel mode. The processor switches between the two modes depending on what type of code is running on the processor. Applications run in user mode, and core operating system components run in kernel mode. While many drivers run in kernel mode, some drivers may run in user mode.

When you start a user-mode application, Windows creates a process for the application. The process provides the application with a private virtual address space and a private handle table. Because an application’s virtual address space is private, one application cannot alter data that belongs to another application. Each application runs in isolation, and if an application crashes, the crash is limited to that one application. Other applications and the operating system are not affected by the crash.

In addition to being private, the virtual address space of a user-mode application is limited. A processor running in user mode cannot access virtual addresses that are reserved for the operating system. Limiting the virtual address space of a user-mode application prevents the application from altering, and possibly damaging, critical operating system data.

All code that runs in kernel mode shares a single virtual address space. This means that a kernel-mode driver is not isolated from other drivers and the operating system itself. If a kernel-mode driver accidentally writes to the wrong virtual address, data that belongs to the operating system or another driver could be compromised. If a kernel-mode driver crashes, the entire operating system crashes.

This diagram illustrates communication between user-mode and kernel-mode components.

error in windows 10 unexpected kernel mode trap

Need help in error for windows 10 unexpected kernel mode trap, it keeps coming and can’t find any best solution.

Replies (43) 

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

Thank you for your interest in Windows 10.

I suggest you to follow the methods below and check if it helps:

Method 1

Disconnect all the external devices (printers, scanner, USB (universal serial bus) drives, etc. ) Except mouse and the keyboard and then boot up.

If this corrects the issue then add the devices back one at a time until you discover the piece of hardware causing the issue. Then get updated drivers software for that particular device

Method 2 : Safe mode

I suggest you to boot the computer to Safe Mode and check if the issue occurs or not. Safe mode starts Windows with a limited set of files and drivers. Startup programs don’t run in safe mode, and only the basic drivers needed to start Windows are installed. Follow the article below to boot the computer to safe mode.

Refer the article to boot to Safe Mode:

Method 3: Run Memory Diagnostics

I suggest you to run Windows Memory Diagnostics utility. Windows 8.1 includes built-in features to help you identify and diagnose problems with memory. Refer to the steps below:

1. Press Windows key + R on the Keyboard.
2. Type mdsched.exe in the Search box, and then press Enter.
3. Choose whether to restart the computer and run the tool immediately or schedule the tool to run at the next restart.
4. Windows Memory Diagnostics runs automatically after the computer restarts and performs a standard memory test automatically. If you want to perform fewer or more tests, press F1, use the Up and Down arrow keys to set the Test Mix as Basic, Standard, or Extended, and then press F10 to apply the desired settings and resume testing.
5. When testing is completed, the computer restarts automatically. You’ll see the test results when you log on.

Method 4: Run Check Disk

I suggest you to run Check Disk which performs an analysis of the disk. Refer to the steps below:

1. Press Windows key + X.
2. Click on Command prompt (Admin).
3. Type chkdsk /f and hit enter.

NOTE: The root drive has to be C: and the command may schedule a task at the system startup, if it does, then press Y to schedule a task and restart the computer to perform chkdsk.

Important: While performing chkdsk on the hard drive if any bad sectors are found on the hard drive when chkdsk tries to repair that sector if any data available on that might be lost.

Hope this information is helpful. Please do let us know if you need further assistance, we’ll be glad to assist you.