RDTSC无法可靠检测单步调试，因其TSC值受频率缩放、多核调度、虚拟化伪造及中断延迟等干扰，导致时间差波动大、阈值失效；真正耗时的是调试器异常处理与上下文切换（毫秒级），远超指令周期（纳秒级）。
为什么 RDTSC 不能可靠检测单步调试
直接说结论：RDTSC 指令本身无法稳定、可靠地检测是否被单步调试。它返回的是处理器自上电以来的时钟周期计数（TSC），但现代 CPU 的 TSC 行为受多种因素干扰——比如频率动态缩放（Intel SpeedStep / AMD Cool'n'Quiet）、多核调度迁移、虚拟化环境下的 TSC 虚拟化，甚至 Windows 内核的 KeQueryPerformanceCounter 都可能重映射为非真实 TSC。当你在调试器中单步执行时，真正增加的延迟往往来自调试器的断点处理、上下文保存/恢复、以及用户态到内核态的多次切换，这些时间远大于几条指令本身的周期开销，RDTSC 测出来的“差值”波动极大，根本无法设定有效阈值。
单步调试时实际发生的关键延迟环节
你以为单步是“CPU 多跑几 cycle”，其实不是。真正耗时的是调试器介入过程：
- 调试器在目标指令前插入
INT 3（或利用硬件断点触发异常） - CPU 切换到 Ring 0，压栈、查 IDT、跳转至
KiTrap03或对应异常处理例程 - 内核将控制权交还给调试器（通过
DbgkpPostFakeProcessCreateMessage等机制） - 调试器读取寄存器、更新 UI、等待用户操作（哪怕只是按 F10）
- 再发
ContinueDebugEvent，内核恢复线程——这整个过程通常在毫秒级，比几条指令的纳秒级 TSC 差高出 10⁵ 倍以上
用 RDTSC 做简单时序探测的实操陷阱
如果你仍想尝试用 RDTSC 做轻量探测（例如判断某段密集计算是否被明显拖慢），必须绕过常见误判点：
- 必须用
__rdtscp（带序列化）而非裸RDTSC，否则编译器/CPU 乱序执行会让前后读数失去可比性 - 两次读数之间只能放极简逻辑（如
mov eax, 1; add eax, 2），避免函数调用、内存访问、分支预测失败 - 需在同一线程、同一逻辑核上运行（绑核：
SetThreadAffinityMask(GetCurrentThread(), 1)），否则跨核 TSC 可能不同步 - 重复采样至少 10 次取中位数，剔除异常值；单次
rdtscp差值低于 500 cycles 才算“疑似未被干扰” - 在 Release + /O2 下编译，Debug 模式下编译器插入的检查代码（如
__RTC_CheckEsp）会彻底污染结果
示例片段（x64 MSVC）：
立即学习“C++免费学习笔记（深入）”；
unsigned __int64 t0, t1; __rdtscp(&aux); // aux 是无用输出，仅用于序列化 // 这里只放 3~5 条无依赖 ALU 指令 volatile int x = 1; x += 2; x *= 3; __rdtscp(&aux); // t1 - t0 若持续 > 2000，才值得怀疑（但不等于“正在被单步”）
真正有效的反单步思路是什么
靠时序差是碰运气，真正有实效的检测都基于调试器行为特征：
- 检查
IsDebuggerPresent()和CheckRemoteDebuggerPresent()—— 它们读取 PEB 中的BeingDebugged和NtGlobalFlag字段，只要没被隐藏就准 - 用
NtQueryInformationProcess查询ProcessDebugPort，非零即被调试（比 API 更底层） - 尝试向当前进程写入已知地址（如 PEB）并捕获
EXCEPTION_ACCESS_VIOLATION：调试器常会拦截该异常并静默处理，导致你的SetUnhandledExceptionFilter不被调用 - 检测硬件断点寄存器状态（
GetThreadContext读Dr0–Dr3），但仅对用户态调试器有效，且需要 SeDebugPrivilege
所有这些方法都比 RDTSC 差值靠谱得多——因为它们查的是“调试器是否已挂上”，而不是猜“它有没有偷偷多花时间”。时序检测唯一适合的场景，是嵌入式或裸机环境下对固定频率 CPU 做指令级性能分析，而非通用反调试。
