__try/__except 无法捕获硬件断点异常，因其触发的调试异常（0x80000003）由内核调试子系统直接处理，不进入用户态SEH链；检测需用GetThreadContext配合挂起线程与CONTEXT_DEBUG_REGISTERS标志。
__try/__except 不能捕获硬件断点异常
直接说结论：__try/__except 是 Microsoft C/C++ 编译器提供的结构化异常处理（SEH）机制，它**只捕获 Windows SEH 异常（如访问违例、除零、INT3 软中断等），但无法捕获由 DR0–DR3 硬件断点触发的 #DB（Debug Exception）**。因为硬件断点触发时，CPU 产生的是调试异常（Exception Code 0x80000003），该异常默认由 Windows 内核的调试子系统接管，**不会向下分发到用户态 SEH 链**，除非进程处于被调试状态（即 IsDebuggerPresent() 为 true）且调试器未处理该异常——但这不是可靠路径。
检测 DR0–DR3 是否被设置，只能靠读取调试寄存器
Windows 用户态程序**无法直接用 mov eax, dr0 读取 DRx 寄存器**——这会触发一般性保护异常（STATUS_ACCESS_VIOLATION）。唯一合法方式是通过 Windows API GetThreadContext() 获取当前线程上下文，其中包含 CONTEXT_DEBUG_REGISTERS 标志位启用的 DR0–DR3 值。注意：
- 必须先挂起目标线程（
SuspendThread()），否则GetThreadContext()可能返回不一致值 - 需在
CONTEXT结构中显式设置CONTEXT_DEBUG_REGISTERS | CONTEXT_CONTROL标志，否则 DRx 字段为 0 - DR0–DR3 存储的是触发断点的线性地址；DR7 的低 16 位（
dr7 & 0xFFFF）才表示各断点是否启用及类型（执行/写入/数据读写）
示例关键片段：
CONTEXT ctx = {0};
ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS | CONTEXT_CONTROL;
if (GetThreadContext(GetCurrentThread(), &ctx)) {
if (ctx.Dr0 || ctx.Dr1 || ctx.Dr2 || ctx.Dr3) {
// 至少一个硬件断点已设
DWORD dr7 = static_cast<DWORD>(ctx.Dr7);
bool is_dr0_enabled = (dr7 & 0x00000001) && (dr7 & 0x00000003) == 0x00000003;
}
}
想拦截硬件断点触发？得用 SetUnhandledExceptionFilter 或 Vectored Exception Handler
__try/__except 不行，但你可以注册顶层异常处理器来捕获 0x80000003 异常。不过要注意：
立即学习“C++免费学习笔记（深入）”；
-
SetUnhandledExceptionFilter()注册的函数**仅在无调试器且无其他 SEH 处理器捕获时生效**；一旦有调试器（哪怕只是IsDebuggerPresent()为 true），该异常大概率被调试器截走 - 更可靠的方案是
AddVectoredExceptionHandler(1, handler)，它优先级高于 SEH，且能收到所有用户态异常，包括0x80000003 - handler 中需检查
ExceptionRecord->ExceptionCode == 0x80000003，再结合ExceptionRecord->ExceptionAddress与 DR0–DR3 值比对，才能确认是否命中硬件断点 - 返回
EXCEPTION_CONTINUE_EXECUTION可让程序继续运行（绕过断点），但需清除 DRx 或 DR7 对应位，否则下一次执行仍触发
实际反调试中，DRx 检测本身就有严重局限
现代调试器（如 x64dbg、WinDbg）默认不使用 DR0–DR3，而是用内存断点（INT3）、ETW 或内核钩子。所以单纯检测 DRx 几乎无效。更麻烦的是：
- 普通用户程序调用
GetThreadContext()读 DRx，需要SE_DEBUG_NAME权限（通常只有 SYSTEM 或调试进程才有） - 即使有权限，若目标线程正在执行（未挂起），DRx 值可能被内核临时修改（如内核调试支持启用时）
- DR0–DR3 是线程局部的，你检测的只是当前线程，而调试器可能在其他线程设断点
真正稳定的做法不是“检测有没有断点”，而是观察行为：比如反复读写某地址看是否变慢、检查 KernelBase!NtQueryInformationProcess 返回的 ProcessDebugPort、或用 WaitForDebugEvent 尝试自附加——这些比抠 DRx 寄存器靠谱得多。
