Windows下新建进程附加调试器时断点异常不一致问题问询

问题现象 #

通过CREATE_SUSPENDED创建挂起进程，调用DebugActiveProcess附加调试器后恢复线程，调试循环中有时会捕获到2个断点异常（来自ntdll.dll:LdrpDoDebuggerBreak和ntdll.dll:DbgBreakPoint），有时仅捕获到1个（仅LdrpDoDebuggerBreak），结果存在随机性。

代码示例：

STARTUPINFO sinfo = { 0 };
sinfo.cb = sizeof(sinfo);

PROCESS_INFORMATION pinfo = { 0 };

DWORD flags = 0;
flags |= CREATE_SUSPENDED;

CreateProcess(TEXT("C:\\windows\\system32\\notepad.exe"), 0, 0, 0, FALSE, flags, 0, 0, &sinfo, &pinfo);

DebugActiveProcess(pinfo.dwProcessId);
DEBUG_EVENT dbg;
ResumeThread(pinfo.hThread);

while (true)
{
    if (WaitForDebugEvent(&dbg, 100))
    {
        switch (dbg.dwDebugEventCode) {

        case EXCEPTION_DEBUG_EVENT:
            printf("exception: 0x%p [%p] (tid: %d)\n", dbg.u.Exception.ExceptionRecord.ExceptionAddress, dbg.u.Exception.ExceptionRecord.ExceptionCode, dbg.dwThreadId);
            break;
        }

        ContinueDebugEvent(dbg.dwProcessId, dbg.dwThreadId, DBG_CONTINUE);
    }
}

两种典型输出：

• 捕获2个异常：

exception: 0x00007FF9E1FE0950 [0000000080000003] (tid: ...)
exception: 0x00007FF9E1FB0BB0 [0000000080000003] (tid: ...)

• 仅捕获1个异常：

exception: 0x00007FF9E1FE0950 [0000000080000003] (tid: ...)

原因分析 #

这两个断点的作用及竞态产生的原因：

• LdrpDoDebuggerBreak：系统加载器在进程初始化阶段触发的断点，用于通知调试器进程已完成初始化准备。
• DbgBreakPoint：进程初始化过程中系统触发的显式断点，能否被捕获取决于调试器附加完成的时机与线程执行进度的竞态。

当用CREATE_SUSPENDED创建进程后，调用DebugActiveProcess再恢复线程时，存在两种时序：

1. 调试器在主线程执行到DbgBreakPoint前完成附加：此时两个断点都会被调试器捕获。
2. 主线程在调试器完成附加前就执行过了DbgBreakPoint：此时调试器只能捕获到LdrpDoDebuggerBreak，因为后者的执行时机更晚，而DbgBreakPoint已经执行完毕。

这种随机性完全源于附加操作与线程执行之间缺乏同步机制，属于非设计场景下的预期表现。

另外，CreateProcess的DEBUG_ONLY_THIS_PROCESS/DEBUG_PROCESS标志是Windows官方设计的调试新进程的标准方式——调试器从进程创建之初就被绑定，所有初始化阶段的调试事件都会被稳定捕获，不会出现竞态问题。

解决方案 #

要获得稳定的捕获行为，有两种可行方案：

1. 使用CreateProcess的调试标志（推荐） #

直接在创建进程时指定DEBUG_ONLY_THIS_PROCESS或DEBUG_PROCESS，确保调试器从进程创建开始就接管所有调试事件，每次都能稳定捕获两个断点。

修改后的代码示例：

STARTUPINFO sinfo = { 0 };
sinfo.cb = sizeof(sinfo);

PROCESS_INFORMATION pinfo = { 0 };

// 组合调试标志与挂起标志
DWORD flags = DEBUG_ONLY_THIS_PROCESS | CREATE_SUSPENDED;

CreateProcess(TEXT("C:\\windows\\system32\\notepad.exe"), 0, 0, 0, FALSE, flags, 0, 0, &sinfo, &pinfo);

DEBUG_EVENT dbg;
ResumeThread(pinfo.hThread);

while (true)
{
    // 使用INFINITE等待更合理，避免错过调试事件
    if (WaitForDebugEvent(&dbg, INFINITE))
    {
        switch (dbg.dwDebugEventCode) {
        case EXCEPTION_DEBUG_EVENT:
            printf("exception: 0x%p [%p] (tid: %d)\n", 
                   dbg.u.Exception.ExceptionRecord.ExceptionAddress, 
                   dbg.u.Exception.ExceptionRecord.ExceptionCode, 
                   dbg.dwThreadId);
            break;
        }

        ContinueDebugEvent(dbg.dwProcessId, dbg.dwThreadId, DBG_CONTINUE);
    }
}

2. 附加后等待调试器关联完成（不推荐） #

如果必须使用DebugActiveProcess的方式，可以在附加后短暂等待再恢复线程，但这种方式依赖系统调度，无法保证绝对稳定，仅适合测试场景。例如在DebugActiveProcess后添加Sleep(100)再调用ResumeThread，但这不是可靠的解决方案。

结论 #

这种随机性是非设计场景下的预期行为——DebugActiveProcess的设计目标是附加到已运行的进程，而非调试刚创建的挂起进程的初始化阶段。要稳定捕获所有初始化阶段的断点，必须使用CreateProcess的DEBUG_ONLY_THIS_PROCESS或DEBUG_PROCESS标志。

内容的提问来源于stack exchange，提问作者Nimce