Debugging Tools for Windows |
The debugger engine supports debugging different types of targets, user-mode and kernel-mode targets, live targets and crash dump files, and local and remote targets. There are different methods for connecting the engine to these different types of targets.
Both user-mode, and kernel-mode crash-dump files are opened with OpenDumpFile. The engine is also able to create dump files from a target with WriteDumpFile2.
The debugger engine can both create and attach to user-mode processes.
Creating a process is done by providing a command line, and optionally an initial directory and environment, for the new process. The engine can then connect to the new process, or keep the new process suspended while it connects to another process. For example, when debugging an application that consists of both a client and server, it is possible to create a client in a suspended state and attach to an already running server, allowing server breakpoints to be set before the client runs and provokes server operations.
When detaching from a process, the engine can optionally leave the process running normally, kill the process, or abandon the process (leaving it suspended until another debugger attaches to it or it is killed).
The engine can be queried for information about all of the user-mode processes that are running on the computer, including the process ID and name of the executable image that is used to start the process. This information can be used to help locate a process to debug.
The method AttachKernel connects the debugger engine to a Windows kernel.
When using the debugger engine to debug remotely, there are potentially two extra steps:
Now the client can tell the host engine to acquire a target through the process server or kernel connection server.
When acquiring a target, the acquisition of the target is not complete until the target generates an event. Typically, this means first calling a method to attach the debugger to the target, then calling WaitForEvent to let the target generate an event. This still holds true when the target is a crash dump file, as these always store an event‑typically the event that caused the dump file to be created.
For details about attaching to targets, see Connecting to Targets.