\n\nThis page has been machine-translated from the original page.
\n
This is a spin-off from the previously created Cheat Sheet for Dump Analysis and Live Debugging with WinDbg, summarizing how to inspect OS process information using WinDbg.
\nSince this is a personal set of notes, more content will be added over time.
\n\nAll content in this article is based solely on publicly available information, published books, or results verified in a personal test environment.
\nRelated articles:
\nIn Windows, a process is fundamentally created as a container that holds one or more threads.
\nWithin the OS, a process is represented by the Executive Process (EPROCESS) structure.
\nThis structure contains process attributes and pointers to related data structures, and the EPROCESS structure functions as a process object. (The Executive’s Object Manager encapsulates an EPROCESS structure as a single process object.)
\nThe EPROCESS structure information itself can be viewed by running the dt nt!_EPROCESS command in a kernel debugger.
The output is attached here for reference. For a conceptual overview, the diagram in Figure 3-2 of Windows Internals is recommended.
\nThe EPROCESS structure has a Process Control Block (PCB) as its first field.
\nThe PCB is a KPROCESS-typed structure used for kernel processes.
\nKPROCESS stores information used by the system kernel, including the dispatcher, scheduler, and interrupt-related data.
\nMost of the data held by the EPROCESS structure resides in the system address range.
\nTherefore, commands that reference EPROCESS structure information, such as .process, cannot be used in user-mode process dumps.
However, each process’s PEB, which is accessed from user mode, is stored in the user-mode address range.
\nAs mentioned above, the ActiveProcessLinks field of the EPROCESS structure is a doubly-linked list that connects all running processes in the OS.
Therefore, by enumerating the ActiveProcessLinks entries, you can reference all process information in the system. (Some malware tampers with the ActiveProcessLinks list to hide rogue processes.)
To dump the ActiveProcessLinks list, first retrieve the information from nt!PsActiveProcessHead.
nt!PsActiveProcessHead stores a pointer to the ActiveProcessLinks of the very first system process created.
In other words, by subtracting the ActiveProcessLinks offset from the address indicated by the pointer in nt!PsActiveProcessHead, you can obtain the address of the EPROCESS structure corresponding to the system process.
By passing the list address to the -l option of the dt command, you can walk the list and dump the information. Running the following commands in sequence enumerates the EPROCESS structures in the system, producing output equivalent to .process 0 0.
# Get the pointer address to the System process's ActiveProcessLinks\nr $t0 = nt!PsActiveProcessHead;r $t1 = poi(@$t0);r $t1\n\n# Check the offset of ActiveProcessLinks.Flink\ndt nt!_EPROCESS ActiveProcessLinks\n> +0x448 ActiveProcessLinks \n\n# Dump _EPROCESS (output equivalent to .process 0 0)\ndt nt!_EPROCESS -l ActiveProcessLinks.Flink -y Ima -yoi Uni $t1-0x448Reference: dt (Display Type) - Windows drivers | Microsoft Learn
\nYou can also explore processes in the system using the commands described in Enumerating Process Information.
\nBelow is a reference example.
\n# Enumerate all processes in the system\n!process 0 0\n\n# Get full details for a specific process\n!process 0 7 notepad.exe\n\n# Switch the debugger context to the specified process (enables commands like !peb)\n.process /r /P <EPROCESS block address identified with !process>\n\n# Walk all processes (can also issue commands against every process)\n!for_each_processIn Windows, certain processes are treated as protected processes.
\nWhen a process is protected, debugging operations such as reading/writing the protected process’s memory or suspending its threads are significantly restricted, even if you hold the Debug privilege.
The protected process mechanism is used for system processes, security software, and media protected by DRM, among others.
\nReference: Debug Privilege - Windows drivers | Microsoft Learn
\nYou can identify a process’s protection level using Process Explorer, as shown below.
\nAccording to Windows Internals, all documented process creation functions ultimately call the native API CreateProcessInternalW, which is defined in Kernel32.dll.
Process creation functions include CreateProcess, which launches a process using the same access token as the calling process, and CreateProcessAsUser, which launches a process using a specified access token. (Others include CreateProcessWithTokenW and CreateProcessWithLogonW.)
Referring to the Docs, the following code simply calls the CreateProcess function.
#include <stdio.h>\n#include <windows.h>\n\nvoid main()\n{\n STARTUPINFO si;\n PROCESS_INFORMATION pi;\n\n WCHAR t1[] = L\"c:\\\\Windows\\\\System32\\\\notepad.exe\";\n LPWSTR lpCommandLine = t1;\n\n ZeroMemory(&si, sizeof(si));\n si.cb = sizeof(si);\n ZeroMemory(&pi, sizeof(pi));\n\n /*\n BOOL CreateProcessW(\n [in, optional] LPCWSTR lpApplicationName,\n [in, out, optional] LPWSTR lpCommandLine,\n [in, optional] LPSECURITY_ATTRIBUTES lpProcessAttributes,\n [in, optional] LPSECURITY_ATTRIBUTES lpThreadAttributes,\n [in] BOOL bInheritHandles,\n [in] DWORD dwCreationFlags,\n [in, optional] LPVOID lpEnvironment,\n [in, optional] LPCWSTR lpCurrentDirectory,\n [in] LPSTARTUPINFOW lpStartupInfo,\n [out] LPPROCESS_INFORMATION lpProcessInformation\n );\n */\n \n if (!CreateProcess(\n NULL, // No module name (use command line)\n lpCommandLine, // Command line\n NULL, // Process handle not inheritable\n NULL, // Thread handle not inheritable\n FALSE, // Set handle inheritance to FALSE\n 0, // No creation flags\n NULL, // Use parent's environment block\n NULL, // Use parent's starting directory \n &si, // Pointer to STARTUPINFO structure\n &pi) // Pointer to PROCESS_INFORMATION structure\n )\n {\n printf(\"CreateProcess failed (%d).\\n\", GetLastError());\n return;\n }\n\n // Wait until child process exits.\n WaitForSingleObject(pi.hProcess, INFINITE);\n\n // Close process and thread handles. \n CloseHandle(pi.hProcess);\n CloseHandle(pi.hThread);\n}Reference: CreateProcessW function (processthreadsapi.h) - Win32 apps | Microsoft Learn
\nReference: STARTUPINFOA (processthreadsapi.h) - Win32 apps | Microsoft Learn
\nBuilding and debugging this program confirmed that CreateProcessInternalW is indeed called after the API invocation.