Debugging Windows applications

Most Windows debuggers use the debug API that is provided by dbghelp.dll. The most interesting functions of this DLL are

DebugActiveProcess() to establish a connection between the debugger and the debugee
WaitForDebugEvent()
DebugBreakProcess()

Other functions that allow the debugger to interact with the target process include

GetThreadContext() and SetThreadContext()
GetThreadSelectorEntry()
ReadProcessMemory() and WriteProcessMemory()
FlushInstructionCache()

If a process is being debugged, it can communicate with the debugger with functions like

OutputDebugString()
DebugBreak()
FatalExit()

Exceptions

When an application that is debugged encounters an exception in user mode, the kernel traps the exception and passes it to the (user mode) exception dispatcher.

the debugger. This seems to be the first chance exception.

If the debugger does not handle the exception, the user mode dispatcher checks for one (or more) installed vectored exception handlers (VEHs) and calls them until one handles the exception.

If none of the VEHs handled the exception, the chain of structured exception handlers is traversed until a SEH is found that handles the exception.

If none of the SEHs handles the exception, the exception is raised again

Kernel mode debugging

The two (Microsoft) debuggers that allow kernel mode debugging are kd.exe and windbg.exe.

Two computers, a target and a host, are needed for kernel mode debugging. These are connect by a

null cable,
IEEE 1394 cable,
a USB 2.0/3.0 cable
a local network or
named pipe (if connected to a hypervisor)

The target computer must be booted in debugging mode which can be configured with bcdedit.exe or msconfig.exe.

TODO: is the ability to connect to the debugged computer with a local network related to the kdnic.sys driver?

TODO

PSRVTABLE, KeServiceDescriptorTable (As found in RegMon source REGSYS.C).

DbgShell, a PowerShell front-end for the Windows debugger engine (dbgeng.dll).

CreateRemoteThread to inject a thread into a process

CreateRemoteThread is commonly used to inject a thread into a process that is being debugged in order to issue a break or query heap and other process information.

This technique is however not recommended because extra thread is confusing to the person debugging the application and there are several side effects to using this technique, including

Conversion of single thread applications to mutlithreaded ones
Changing the timing and memory layout of the process
Calling the entry point of each DLL in the process

LdrpDoDebuggerBreak

What's the thing with LdrpDoDebuggerBreak, as often seen when using Debugging tools for Windows:

… ntdll!LdrpDoDebuggerBreak+0x30
… ntdll!LdrpInitializeProcess+0x1f42
… ntdll!LdrpInitialize+0x15f
… ntdll!LdrpInitialize+0x3b
… ntdll!LdrInitializeThunk+0xe