.process (Set Process Context)

The .process command specifies which process is used for the process context.

.process [/i] [/p [/r]] [/P] [Process]

Parameters

/i
Live debugging only; not during local kernel debugging) Specifies that Process is to be debugged invasively. This kind of debugging means that the operating system of the target computer actually makes the specified process active. (Without this option, the .process command alters the debugger's output but does not affect the target computer itself.) If you use /i, you must use the g (Go) command to execute the target. After several seconds, the target breaks back in to the debugger, and the specified Process is active and used for the process context.

/p
Translates all transition page table entries (PTEs) for this process to physical addresses before access, if you use /p and Process is nonzero. This translation might cause slowdowns, because the debugger must find the physical addresses for all of the memory that this process uses. Also, the debugger might have to transfer a significant amount of data across the debug cable. (This behavior is the same as .cache forcedecodeuser.)

If you include the /p option and Process is zero or you omit it, the translation is disabled. (This behavior is the same as .cache noforcedecodeptes.)

/r
Reloads user-mode symbols after the process context has been set, if you use the /r and /p options. (This behavior is the same as .reload /user.)

/P
(Live debugging and complete memory dumps only) Translates all transition page table entries (PTEs) to physical addresses before access, if you use /P and Process is nonzero. Unlike the /p option, the /P option translates the PTEs for all user-mode and kernel-mode processes, not only the specified process. This translation might cause slowdowns, because the debugger must find the physical addresses for all memory in use. Also, the debugger might have to transfer lots of data across the debug cable. (This behavior is the same as .cache forcedecodeptes.)

Process
Specifies the address of the process that you want. (More precisely, this parameter specifies the address of the EPROCESS block for this process). The process context is set to this process. If you omit Process or specify zero, the process context is reset to the default process for the current system state. (If you used the /i option to set process context, you must use the /i option to reset the process context.)

Environment

Item	Description
Modes	kernel mode only
Targets	live, crash dump
Platforms	all

Additional Information

For more information about the process context and other context settings, see Changing Contexts.

Remarks

Typically, when you are doing kernel debugging, the only visible user-mode address space is the one that is associated with the current process.

The .process command instructs the kernel debugger to use a specific user-mode process as the process context. This usage has several effects, but the most important is that the debugger has access to the virtual address space of this process. The debugger uses the page tables for this process to interpret all user-mode memory addresses, so you can read and write to this memory.

The .context (Set User-Mode Address Context) command has a similar effect. However, the .context command sets the user-mode address context to a specific page directory, while the .process command sets the process context to a specific process. On an x86-based processor, .context and .process have almost the same effect. However, on an Itanium-based processor, a single process might have more than one page directory. In this situation, the .process command is more powerful, because it enables access to all of the page directories that are associated with a process. For more information about the process context, see Process Context.

Note   If you are performing live debugging, you should use the /i or the /p parameter. Without one of these parameters, you cannot correctly display user-mode or session memory.

The /i parameter activates the target process. When you use this option, you must execute the target once for this command to take effect. If you execute again, the process context is lost.

The /p parameter enables the forcedecodeuser setting. (You do not have to use /p if the forcedecodeuser option is already active.) The process context and the forcedecodeuser state remain only until the target executes again.

If you are performing crash dump debugging, the /i and /p options are not available. However, you cannot access any part of the user-mode process' virtual address space that were paged to disk when the crash occurred.

If you want to use the kernel debugger to set breakpoints in user space, use the /i option to switch the target to the correct process context.

The following example shows how to use the !process extension to find the address of the EPROCESS block for the desired process.

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS fe5039e0  SessionId: 0  Cid: 0008    Peb: 00000000  ParentCid: 0000
    DirBase: 00030000  ObjectTable: fe529b68  TableSize:  50.
    Image: System

.....

PROCESS fe3c0d60  SessionId: 0  Cid: 0208    Peb: 7ffdf000  ParentCid: 00d4
    DirBase: 0011f000  ObjectTable: fe3d0f48  TableSize:  30.
    Image: regsvc.exe

Now the example uses the .process command with this process address.

kd> .process fe3c0d60
Implicit process is now fe3c0d60

Notice that this command makes the .context command unnecessary. The user-mode address context already has the desired value.

kd> .context 
User-mode page directory base is 11f000

This value enables you to examine the address space in various ways. For example, the following example shows the output of the !peb extension.

kd> !peb
PEB at 7FFDF000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            No
    ImageBaseAddress:         01000000
    Ldr.Initialized: Yes
    Ldr.InInitializationOrderModuleList: 71f40 . 77f68
    Ldr.InLoadOrderModuleList: 71ec0 . 77f58
    Ldr.InMemoryOrderModuleList: 71ec8 . 77f60
        01000000 C:\WINNT\system32\regsvc.exe
        77F80000 C:\WINNT\System32\ntdll.dll
        77DB0000 C:\WINNT\system32\ADVAPI32.dll
        77E80000 C:\WINNT\system32\KERNEL32.DLL
        77D40000 C:\WINNT\system32\RPCRT4.DLL
        77BE0000 C:\WINNT\system32\secur32.dll
    SubSystemData:     0
    ProcessHeap:       70000
    ProcessParameters: 20000
        WindowTitle: "'C:\WINNT\system32\regsvc.exe'"
        ImageFile:    'C:\WINNT\system32\regsvc.exe'
        CommandLine:  'C:\WINNT\system32\regsvc.exe'
        DllPath:     'C:\WINNT\system32;.;C:\WINNT\System32;C:\WINNT\system;C:\WINNT;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\PROGRA~1\COMMON~1\AUTODE~1'
        Environment:  0x10000