企业官网建设流程全解析

1. 项目概述：为什么我们要从零手写一个C++调试器？

如果你是一名Windows平台的C++开发者，调试器对你来说就像空气和水一样不可或缺。Visual Studio的调试器固然强大，但你是否曾好奇过，当你按下F5，程序停在断点处时，背后究竟发生了什么？那些反汇编窗口、寄存器视图、内存监视器，它们是如何与你的程序“对话”的？这个项目，就是一次彻底的“造轮子”之旅，目标是用C++从零开始，打造一个功能上模仿经典逆向工具OllyDbg的调试器。这不仅仅是一个编程练习，更是一次深入Windows操作系统核心、理解程序执行本质的绝佳机会。通过亲手实现进程创建、断点设置、内存读写、指令反汇编这些底层功能，你将彻底摆脱对集成开发环境（IDE）调试器的“黑盒”依赖，建立起对程序调试、乃至软件安全领域的深刻认知。无论你是想深入系统编程，还是对逆向工程、漏洞分析感兴趣，这个项目都将为你打下坚实的地基。

2. 调试器核心架构与设计思路拆解

一个调试器，本质上是一个特殊的“监视者”程序。它通过操作系统提供的特殊接口，附着在另一个程序（被调试进程）上，能够拦截其执行、窥探其内存、并控制其流程。我们的仿OllyDbg调试器，其核心设计遵循了经典的“事件驱动”模型。

2.1 核心工作流程：事件循环驱动

调试器的核心是一个永不停止的循环，我们称之为“调试事件循环”。它不断地向操作系统询问：“被调试的程序有没有发生什么有趣的事？” 这个过程主要依赖于三个关键的Windows API：CreateProcess（或DebugActiveProcess）、WaitForDebugEvent和ContinueDebugEvent。

当调试器启动或被附加到一个进程后，该进程就进入了“被调试”状态。此后，该进程发生的许多关键事件（如创建新线程、加载DLL、触发异常、进程退出等）都会被操作系统暂停，并作为“调试事件”通知给调试器。调试器的主循环就是不断地调用WaitForDebugEvent来接收这些事件，分析它们，做出响应（比如在断点处停下来显示信息），然后调用ContinueDebugEvent告诉操作系统：“处理完了，让被调试进程继续跑吧”。

这个模型清晰地将调试器的逻辑划分为：事件等待、事件分发、事件处理、恢复执行四个阶段。我们的调试器引擎（DbgEngine类）就是围绕这个循环构建的。

2.2 模块化设计：面向对象的架构

为了管理复杂度，我们采用了高度模块化的面向对象设计。整个调试器可以看作由几个协同工作的核心引擎构成：

1. 调试引擎 (DbgEngine)：这是大脑和中枢神经。它负责维护调试会话的生命周期，包括启动/附加进程、运行主调试事件循环、分发事件到各个处理器。它持有被调试进程和线程的句柄，是其他模块与操作系统调试API交互的桥梁。

2. 断点引擎 (BreakpointEngine)：这是最精巧的部件之一。断点是调试器的灵魂，我们实现了多种类型的断点，它们都继承自一个共同的基类BPObject。这个基类定义了Install()、Remove()、IsHit()等虚函数。具体的断点类型（软件断点BPSoft、硬件断点BPHard、内存断点BPAcc、单步断点BPTF）负责实现这些接口。断点引擎管理着一个BPObject的列表，负责它们的安装、卸载和命中判断。这种设计使得增加新的断点类型变得非常容易。

3. 用户界面 (DbgUi)：负责与用户交互和信息呈现。虽然我们目标是仿OllyDbg的命令行/控制台界面，但依然需要良好的信息组织。DbgUi类负责以对齐、着色的方式格式化显示反汇编代码、寄存器值、内存数据、调用栈等。它直接与Windows控制台API交互，实现彩色输出，让不同信息一目了然。

4. 符号与辅助引擎：依赖dbghelp.dll实现符号加载和栈回溯。依赖BeaEngine进行反汇编，依赖XEDParse进行汇编指令编码。这些模块作为相对独立的组件，为调试器提供高级数据分析能力。

注意：这种“引擎+管理器”的架构模式在系统工具开发中非常常见。它保证了核心逻辑的纯粹性，界面和辅助功能可以独立变化或增强。例如，未来你可以很容易地将DbgUi从控制台替换为图形界面（GUI），而无需重写调试引擎和断点引擎的代码。

3. 核心功能实现细节与实操要点

3.1 建立调试会话：创建与附加

调试器开始工作的第一步，就是和目标程序建立联系。有两种主要方式：

创建新进程进行调试：这是最常用的方式。我们使用CreateProcessAPI，但关键是要传递DEBUG_PROCESS或DEBUG_ONLY_THIS_PROCESS标志。

STARTUPINFO si = { sizeof(si) }; PROCESS_INFORMATION pi = { 0 }; BOOL success = CreateProcess( NULL, // 应用程序名（或在命令行参数中） “target.exe”, // 命令行 NULL, NULL, FALSE, DEBUG_PROCESS, // 关键标志：创建为被调试进程 NULL, NULL, &si, &pi );

成功之后，pi.hProcess和pi.hThread就是调试器操控目标程序的“遥控器”。操作系统会自动将目标进程的所有调试事件转发给调试器。

附加到已运行进程：有时程序已经跑起来了，我们想中途介入。这就需要DebugActiveProcess。

DWORD dwProcessId = 1234; // 目标进程ID HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwProcessId); if (hProcess) { if (DebugActiveProcess(dwProcessId)) { // 附加成功 } }

这里有个关键点：DebugActiveProcess要求调用者（调试器进程）具有足够的权限（通常是PROCESS_ALL_ACCESS或至少包含PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION）。如果附加失败，多半是权限问题，可能需要以管理员身份运行调试器。

实操心得：在开发调试器时，我强烈建议先实现“创建调试”并稳定运行，再去实现“附加调试”。因为创建过程是线性的，从进程生命开始就接管，状态更干净。附加调试则需要处理进程已经运行到一半的复杂状态，比如已有线程、已加载的DLL等，事件处理逻辑需要更健壮。

3.2 调试事件循环：调试器的心跳

这是调试器最核心的循环，代码骨架大致如下：

DEBUG_EVENT dbgEvent = { 0 }; while (!bExit) { // 等待调试事件，INFINITE表示一直等，也可以设置超时 if (!WaitForDebugEvent(&dbgEvent, INFINITE)) { // 出错处理 break; } DWORD dwContinueStatus = DBG_CONTINUE; // 默认继续状态 // 根据事件类型进行分发处理 switch (dbgEvent.dwDebugEventCode) { case EXCEPTION_DEBUG_EVENT: // 处理异常，例如断点命中、单步、访问违规等 dwContinueStatus = HandleExceptionEvent(dbgEvent.u.Exception); break; case CREATE_PROCESS_DEBUG_EVENT: // 进程创建，可以在这里获取主模块基址、初始线程句柄等 HandleCreateProcessEvent(dbgEvent.u.CreateProcessInfo); break; case EXIT_PROCESS_DEBUG_EVENT: // 进程退出，清理资源 HandleExitProcessEvent(dbgEvent.u.ExitProcess); bExit = true; // 可以退出循环了 break; case LOAD_DLL_DEBUG_EVENT: // DLL加载，可以记录模块信息，用于符号加载 HandleLoadDllEvent(dbgEvent.u.LoadDll); break; // ... 处理其他事件：CREATE_THREAD_DEBUG_EVENT, EXIT_THREAD_DEBUG_EVENT等 } // 告诉操作系统，事件处理完毕，让被调试进程继续 ContinueDebugEvent(dbgEvent.dwProcessId, dbgEvent.dwThreadId, dwContinueStatus); }

关键解析：

• EXCEPTION_DEBUG_EVENT是最重要的事件类型。断点触发（EXCEPTION_BREAKPOINT）、单步执行（EXCEPTION_SINGLE_STEP）、内存访问违规（EXCEPTION_ACCESS_VIOLATION）等，都包装在这个事件里。调试器需要根据异常代码和地址来判断这是否是一个“有意为之”的调试事件（比如我们设置的断点），还是一个需要抛给程序处理的“意外”异常。
• dwContinueStatus至关重要。对于大多数调试事件，我们返回DBG_CONTINUE。但对于某些第一次发生的异常（比如程序自己触发的访问违规），如果我们不处理，应该返回DBG_EXCEPTION_NOT_HANDLED，让操作系统去查找程序自身的异常处理器（SEH）。如果错误地处理了不该处理的异常，可能会掩盖程序的真实错误。

3.3 断点系统的实现原理

断点是调试器控制程序执行流的核心手段。我们实现了四种，各有其原理和适用场景。

软件断点 (INT 3)：这是最经典、最常用的断点。原理很简单：在目标地址的指令处，将第一个字节替换为0xCC，这是x86/x64架构下的INT 3（断点中断）指令的机器码。当CPU执行到这里时，会触发一个断点异常（EXCEPTION_BREAKPOINT），被我们的调试事件循环捕获。

// 伪代码：安装软件断点 bool BPSoft::Install() { // 1. 保存原指令字节 ReadProcessMemory(hProcess, address, &originalByte, 1); // 2. 写入0xCC unsigned char breakpointByte = 0xCC; WriteProcessMemory(hProcess, address, &breakpointByte, 1); // 3. 刷新指令缓存（某些架构需要，x86/x64通常不需要） FlushInstructionCache(hProcess, address, 1); return true; }

当断点命中，我们处理完异常后，需要做两件事：1. 将0xCC恢复为原来的指令字节；2. 将指令指针EIP/RIP回退一个字节，因为触发异常时CPU已经将EIP指向了0xCC之后的下一条指令。如果不回退，程序就会跳过原指令直接执行下一条，导致逻辑错误。

硬件断点：利用CPU内置的调试寄存器DR0到DR7。DR0-DR3可以存放最多4个内存地址，DR7是控制寄存器，可以设置每个地址的断点类型（执行、写入、读取/写入）和长度（1, 2, 8字节）。当CPU访问到这些地址并满足条件时，会触发单步异常（EXCEPTION_SINGLE_STEP）。

// 伪代码：安装硬件执行断点 bool BPHard::Install() { CONTEXT ct = { 0 }; ct.ContextFlags = CONTEXT_DEBUG_REGISTERS; GetThreadContext(hThread, &ct); // 找一个空闲的调试寄存器（DR0-DR3） if (ct.Dr0 == 0) { ct.Dr0 = breakpointAddress; // 设置DR7：L0=1启用，RW0=0执行断点，LEN0=0长度1字节 ct.Dr7 |= (1 << 0); // 设置L0位 // ... 更精细的DR7位设置 } else if (ct.Dr1 == 0) { // 使用DR1... } // ... 以此类推 SetThreadContext(hThread, &ct); return true; }

硬件断点的优势是速度快（不修改内存），且可以设置数据访问断点（监视某个变量何时被改写）。劣势是数量极其有限（只有4个），并且是线程相关的（每个线程的上下文独立）。

内存断点：通过VirtualProtectEx函数，将目标内存页的属性改为PAGE_GUARD（守护页）。当程序访问该页的任何地址时，都会触发一个STATUS_GUARD_PAGE_VIOLATION异常。我们在异常处理中判断访问地址是否在我们关心的范围内，以及访问类型（读/写/执行）。

// 伪代码：安装内存访问断点（监视写操作） bool BPAcc::Install() { // 计算目标地址所在的页边界 SYSTEM_INFO sysInfo; GetSystemInfo(&sysInfo); DWORD pageSize = sysInfo.dwPageSize; PVOID pageBase = (PVOID)((DWORD_PTR)address & ~(pageSize - 1)); // 修改页面属性为PAGE_GUARD | PAGE_READWRITE VirtualProtectEx(hProcess, pageBase, pageSize, PAGE_GUARD | PAGE_READWRITE, &oldProtect); return true; }

内存断点可以监视一大片内存区域（一页通常是4KB），但缺点是粒度粗，且每次触发后守护属性会消失，需要重新设置，实现起来较复杂，对性能影响也较大。

单步执行 (Trap Flag)：通过设置EFLAGS/RFLAGS寄存器中的TF（Trap Flag）位为1。CPU每执行完一条指令，就会触发一个单步异常（EXCEPTION_SINGLE_STEP）。调试器处理完异常后，如果想继续单步，必须再次设置TF位。

bool BPTF::Install() { CONTEXT ct = { 0 }; ct.ContextFlags = CONTEXT_CONTROL; GetThreadContext(hThread, &ct); ct.EFlags |= 0x100; // 设置TF位 SetThreadContext(hThread, &ct); return true; }

单步是调试的基石，但通常不直接作为“断点”使用，而是作为“步过(Step Over)”或“步入(Step Into)”功能的实现基础。

注意事项：处理单步异常（EXCEPTION_SINGLE_STEP）时，必须非常小心。这个异常不仅可能由我们设置的硬件断点或单步标志触发，也可能由其他原因（如CPU的DR6寄存器指示的调试异常）触发。需要结合上下文信息仔细判断异常来源，避免错误地“吃掉”异常或陷入死循环。

3.4 内存、寄存器与反汇编的查看与修改

内存操作：核心是ReadProcessMemory和WriteProcessMemory。这里的关键是地址空间。被调试进程有自己独立的虚拟地址空间，调试器不能直接用指针访问，必须通过这两个API。操作前，务必检查地址是否可读/可写（可以用VirtualQueryEx查询内存属性），否则操作会失败。

// 读取目标进程内存 SIZE_T bytesRead = 0; BYTE buffer[256]; if (ReadProcessMemory(hProcess, (LPCVOID)targetAddress, buffer, sizeof(buffer), &bytesRead)) { // 成功读取到buffer中 } else { DWORD err = GetLastError(); // 可能是ERROR_PARTIAL_COPY或ERROR_INVALID_ADDRESS }

寄存器操作：通过GetThreadContext和SetThreadContext。CONTEXT结构体包含了线程的所有寄存器状态。你需要根据架构（x86/x64）和你想操作的寄存器组来设置ContextFlags。

CONTEXT ct = { 0 }; ct.ContextFlags = CONTEXT_INTEGER; // 只获取通用寄存器 if (GetThreadContext(hThread, &ct)) { printf(“EAX = 0x%08X\n”, ct.Eax); // x86 // 修改寄存器 ct.Eax = 0xDEADBEEF; SetThreadContext(hThread, &ct); }

反汇编：这是将内存中的机器码转换为人类可读的汇编指令。我们使用BeaEngine库。你需要提供机器码的起始地址和字节流，它会返回指令的助记符、操作数等详细信息。

// 使用BeaEngine反汇编 DISASM disasm = { 0 }; disasm.EIP = (UIntPtr)codeBuffer; disasm.VirtualAddr = (UInt64)instructionAddress; int len = Disasm(&disasm); if (len != UNKNOWN_OPCODE) { printf(“%p: %s %s\n”, instructionAddress, disasm.Instruction.Mnemonic, disasm.CompleteInstr); }

反汇编引擎的选择很重要，BeaEngine、Capstone、Zydis都是优秀的选择，它们能准确处理复杂的x86/x64指令集。

4. 高级功能与反反调试技术实现

4.1 条件断点与表达式求值

普通的断点是无条件的，每次执行到那里都会停下。条件断点则允许我们设置一个表达式（例如eax == 0x42），只有当表达式为真时，断点才生效。这能极大提高调试效率。

实现思路是：在断点命中时，不立即暂停并通知用户，而是先调用一个表达式求值器。这个求值器需要能够：

1. 解析表达式：将字符串形式的表达式（如“eax == 0x42 && [esp+4] > 100”）解析成语法树。
2. 获取上下文：从当前线程的CONTEXT中获取寄存器值，通过ReadProcessMemory读取指定内存地址的值。
3. 执行计算：按照运算符优先级进行计算。

如果表达式求值为真，则像普通断点一样暂停；如果为假，则自动恢复程序执行（将EIP回退并替换回原指令，或者直接继续，取决于断点类型）。这要求我们的调试器在断点处理逻辑中嵌入一个轻量级的脚本引擎或表达式解析库。

4.2 对抗反调试技术

许多软件，特别是游戏和恶意软件，会使用反调试技术来阻止或干扰调试器分析。我们的调试器要实现“反反调试”，才能顺利工作。常见手段及对抗方法：

1. 检查BeingDebugged标志：Windows在进程环境块（PEB）中提供了一个BeingDebugged字段（偏移0x2）。如果进程被调试，该字段为1。程序可以通过IsDebuggerPresent()API或直接读取PEB来检查。

   • 对抗：在调试器附加或创建进程后，立即通过WriteProcessMemory修改目标进程PEB中的BeingDebugged字段为0。这需要在进程早期（例如在CREATE_PROCESS_DEBUG_EVENT事件中）完成。

2. 检查NtGlobalFlag：PEB中的NtGlobalFlag字段在调试时某些位会被设置（如FLG_HEAP_ENABLE_TAIL_CHECK,FLG_HEAP_ENABLE_FREE_CHECK）。

   • 对抗：同样通过写内存，将NtGlobalFlag清零。

3. API Hook检测：程序可能会HookIsDebuggerPresent、CheckRemoteDebuggerPresent等API，使其永远返回FALSE。或者检测这些API的代码段是否被修改（被调试器下断点）。

   • 对抗：我们的调试器可以实现更底层的断点（硬件断点），或者直接在内核层面隐藏。在用户态，我们可以手动计算这些API的地址并直接调用，或者恢复被Hook的代码。

4. 时间差检测：程序记录一段代码执行前后的时间，如果时间间隔异常长（因为被调试器单步），则判定被调试。

   • 对抗：这很难完美对抗。调试器可以尝试在断点处理时“补偿”时间，或者通过修改程序代码绕过检测点。这属于更高级的攻防对抗。

在我们的项目中，可以在DbgEngine初始化后，调用一个AntiAntiDebug()函数，集中执行上述的PEB修改等操作。

4.3 插件系统设计

为了让调试器功能可扩展，我们设计了一个简单的插件系统。插件以DLL（动态链接库）形式存在，调试器主程序可以在运行时动态加载它们。

插件接口定义：我们定义一个标准的函数导出约定。例如，每个插件DLL必须导出一个名为Plugin_Init的函数，该函数接收一个指向调试器核心引擎的接口指针。通过这个接口，插件可以注册新的命令、添加新的视图窗口、或者挂钩到调试事件上。

// 插件接口示例 typedef struct { const char* name; void (*onDebugEvent)(DEBUG_EVENT*); // 事件回调 void (*registerCommands)(CommandDispatcher*); // 注册自定义命令 } PluginInterface; // 调试器主程序加载插件 HMODULE hDll = LoadLibrary(“my_plugin.dll”); if (hDll) { auto initFunc = (PluginInterface*(*)())GetProcAddress(hDll, “GetPluginInterface”); if (initFunc) { PluginInterface* plugin = initFunc(); plugin->registerCommands(&g_commandDispatcher); g_plugins.push_back(plugin); } }

这样，第三方开发者就可以为调试器开发诸如脚本自动化、网络协议分析、特定文件格式解析等高级功能插件。

5. 开发环境搭建与项目构建实操

5.1 环境准备与依赖库配置

操作系统：Windows 10 或 Windows 11。调试器开发严重依赖Windows SDK，新版本系统通常有更好的兼容性。

开发工具：Visual Studio 2019 或 2022。社区版即可。确保安装时勾选“使用C++的桌面开发”工作负载，它会包含必要的Windows SDK和编译器。

关键依赖库：

1. BeaEngine (v4.1或更高)：用于反汇编。从其官网或GitHub下载源码，编译为静态库（.lib文件）。在VS项目中，需要在“附加包含目录”中添加其头文件路径，在“附加库目录”中添加.lib文件路径，并在“附加依赖项”中添加BeaEngine.lib。
2. XEDParse：用于汇编（将汇编指令字符串编码为机器码）。同样需要编译为静态库并链接。
3. Windows SDK：这是核心，提供了所有必要的调试API（DbgHelp.h,Windows.h等）。通常随Visual Studio安装。

项目配置要点：

• 字符集：建议使用“使用多字节字符集”而非Unicode，避免一些字符串处理的麻烦，但这不是强制要求。
• 运行库：调试器作为独立控制台程序，建议使用/MT（静态链接运行时库），这样生成的可执行文件可以独立运行，不依赖VC++运行时 DLL。但这样会增大文件体积。
• 预处理器定义：可能需要定义_CRT_SECURE_NO_WARNINGS来禁用某些安全警告。
• 调试信息：确保为调试器项目本身生成调试符号（PDB文件）。同时，为了能调试目标程序，也需要确保目标程序编译时生成了调试信息（对于GCC/MinGW是-g，对于MSVC是/DEBUG）。

5.2 核心模块编码与调试技巧

从最小原型开始：不要试图一口气写完所有功能。建议的构建顺序是：

1. 阶段一：建立连接。实现CreateProcesswithDEBUG_PROCESS，并成功运行一个简单的“Hello World”目标程序，调试器能接收到进程创建和退出事件。
2. 阶段二：实现事件循环与基础断点。完善事件循环，处理EXCEPTION_DEBUG_EVENT。实现软件断点（INT3）的安装、触发和恢复。这是第一个里程碑，意味着你能让程序在你指定的位置停下来。
3. 阶段三：实现用户界面与交互。构建一个简单的命令行界面，实现break [address],continue,step等基本命令。将内存、寄存器查看功能与界面连接。
4. 阶段四：丰富功能。逐步加入硬件断点、内存断点、反汇编显示（集成BeaEngine）、符号加载（集成DbgHelp）、条件断点等。

调试调试器：这听起来有点绕。当你开发调试器时，你本身也需要一个调试器（比如VS）来调试你的调试器代码。这被称为“自举”或“双重调试”。一个实用的技巧是：使用两个Visual Studio实例。一个实例运行并调试你的“调试器项目”，另一个实例运行一个简单的“被调试目标程序”。你在第一个VS里单步跟踪你的调试器代码，观察它如何控制第二个VS里的目标程序。这需要一些耐心来设置断点和观察变量。

日志系统是救命稻草：在调试器代码的关键路径（如事件处理、断点安装/移除、内存读写）添加详细的日志输出（写入文件或控制台）。当调试器行为异常时，这些日志是定位问题的最直接依据。例如，记录每个收到的调试事件类型和地址，记录每次ReadProcessMemory的地址和结果。

踩坑实录：在早期开发中，我遇到了一个诡异的问题：设置断点后，程序没有在预期地址停下，而是跑飞了。通过日志发现，WriteProcessMemory写入0xCC成功了，但后续的ReadProcessMemory读回来的却是别的值。最终发现，目标程序启用了地址空间布局随机化（ASLR），我硬编码的地址在每次运行时都不同。解决方案是：通过CREATE_PROCESS_DEBUG_EVENT事件中的lpBaseOfImage获取主模块的实际加载基址，然后加上代码段的相对偏移量（RVA）来计算绝对地址。永远不要假设程序的加载地址是固定的。

6. 常见问题排查与实战心得

在开发和使用自写调试器的过程中，你会遇到各种各样的问题。下面是一些典型问题及其排查思路。

6.1 调试器无法附加到进程

• 症状：DebugActiveProcess返回FALSE，GetLastError可能是5（拒绝访问）或87（参数错误）。
• 排查：
  1. 权限问题：确保你的调试器以管理员身份运行。许多系统进程和受保护的程序需要提升的权限。
  2. 进程ID错误：确认你传递的进程ID（PID）是正确的。使用任务管理器或tasklist命令核对。
  3. 进程已结束：目标进程可能在OpenProcess和DebugActiveProcess调用之间退出了。
  4. 已有调试器附着：一个进程同时只能被一个调试器附着。确保没有其他调试器（如VS、x64dbg）正在调试它。

6.2 断点触发后程序崩溃或行为异常

• 症状：程序在断点处停下，但继续执行后崩溃，或者执行结果不对。
• 排查：
  1. EIP/RIP未正确回退：对于软件断点，触发后必须将指令指针减1（x86）或不做处理（x64下RIP指向下一条指令，但INT3指令长1字节，通常也需要调整）。这是最常见的原因。
  2. 原始字节恢复错误：检查保存和恢复的原始字节是否正确。在多线程环境下，断点可能被其他线程执行，需要考虑线程同步。
  3. 断点设置在指令中间：x86/x64是变长指令集。如果你把断点设在了一条多字节指令的中间（而非开头），恢复时只替换了第一个字节，会导致后续字节解析为错误的指令。确保断点地址是某条指令的起始地址。这需要依赖反汇编引擎来确认。
  4. 代码自修改：有些程序（尤其是加壳或混淆过的）会动态修改自身的代码。你的断点0xCC可能会被程序自身的逻辑覆盖或移动，导致无法触发或恢复错误。

6.3 单步执行陷入死循环

• 症状：启用单步后，程序不停触发EXCEPTION_SINGLE_STEP，无法继续正常执行。
• 排查：
  1. TF标志未清除：处理单步异常后，如果没有清除CONTEXT.EFlags中的TF位，那么CPU执行完下一条指令后会再次触发单步异常，形成死循环。你需要在ContinueDebugEvent之前，通过SetThreadContext清除TF位（除非你想继续单步）。
  2. 硬件断点未清除：硬件断点也通过EXCEPTION_SINGLE_STEP异常报告。如果你设置了硬件断点，但在命中后没有正确地清除或禁用调试寄存器（DR7中的对应控制位），它也会导致每次执行到该地址都触发异常。确保你的断点引擎能正确区分异常来源并处理。

6.4 读取/写入目标进程内存失败

• 症状：ReadProcessMemory或WriteProcessMemory返回FALSE，错误代码为299（ERROR_PARTIAL_COPY）或487（ERROR_INVALID_ADDRESS）。
• 排查：
  1. 地址无效：确认你传入的地址在目标进程的地址空间内且是可访问的。使用VirtualQueryEx查询地址的内存区域属性（MEMORY_BASIC_INFORMATION）。
  2. 权限不足：试图写入只读内存页（如代码段）。需要先用VirtualProtectEx修改页面属性为PAGE_READWRITE，操作完成后再改回去。注意，修改代码段属性可能会触发系统的代码完整性保护。
  3. 跨进程指针：这是新手常犯的错误。你不能直接传递调试器进程内的指针给这些API。所有地址参数都必须是目标进程虚拟地址空间中的地址。

6.5 反汇编显示不正确

• 症状：显示出来的汇编指令乱七八糟，或者指令长度计算错误。
• 排查：
  1. 引擎初始化：确保正确初始化了反汇编引擎（如BeaEngine的Disasm结构体）。
  2. 地址传递：反汇编引擎通常需要两个地址：一个是代码缓冲区的地址（EIP），另一个是这条指令对应的虚拟地址（VirtualAddr）。对于从目标进程内存中读取的代码，VirtualAddr应该设置为该代码在目标进程中的实际虚拟地址，这对解析相对跳转等指令至关重要。
  3. 架构模式：明确设置反汇编引擎为32位（x86）或64位（x64）模式。混合模式程序（如64位进程中的32位代码）需要特别处理。
  4. 缓冲区长度：确保传递给反汇编引擎的代码缓冲区足够长，能包含一条完整的指令。对于x86/x64，最长指令可达15字节，建议每次读取至少16字节。

完成这个项目，你收获的远不止一个可运行的调试器。你将对Windows进程模型、异常分发机制、CPU调试功能、PE文件格式有第一手的深刻理解。这些知识是通向系统编程、安全研究、性能分析等高级领域的钥匙。当你再使用Visual Studio或Windbg时，你会清楚地知道每一个调试操作背后发生的系统调用和硬件交互，这种“透明感”是普通开发者难以企及的。动手开始吧，从创建一个最简单的调试循环开始，每一步遇到的问题和解决过程，都是最宝贵的经验。