简介D3DHook透视实现源码基于C与Direct3D编写面向对游戏逆向、图形编程及Hook机制感兴趣的中高级开发者。工程演示了通过API Hook拦截CreateDevice、Present等关键绘制函数并针对视图矩阵、投影矩阵进行动态修改以实现透视效果的完整流程同时对比了API Hook与VTable Hook的区别内容覆盖Hook挂载、3D数学基础、工程构建与调试要点附有可运行的exe、dll目标文件及完整工程源码。压缩包共71个文件以cpp/h源代码、vcxproj工程配置、tlog编译日志、pdb调试信息为主兼有obj中间文件和pch预编译头等构建产物整体大小67.5MB目录结构清晰便于按模块阅读。目前已有310人浏览学习。对于想深入D3D渲染管线并尝试扩展游戏功能的开发者这份代码提供了从拦截机制到矩阵运算的完整参考实现也是学习游戏调试与逆向分析的实用素材。1. D3D Hook 是什么为什么一个录屏工具和“透视源码”共用同一套技术你在网盘里见过 D3DHOOK.zip 这类压缩包解压后是个 C 工程里面除了 d3d9.h、MinHook 之类的源码还带着透视字样与此同时你桌面右下角那个帧率悬浮窗底层也是 D3D Hook。这类东西的本质是在游戏用 D3D 渲染一帧画面的节奏里把自己的绘制代码插进去让覆盖层跟着游戏画面一起出现。它能做录屏、HUD 定制、无障碍增强这类正经事也常被用来做游戏内辅助工具下面不展开任何破坏游戏公平性的实现。只把 D3D Hook 的调用链、C 落地代码、参数调法和坑位讲清楚。适合想看懂这类源码结构或者需要给自研引擎做调试工具的人。2. D3D9 渲染管线与 Hook 切入点为什么 EndScene 是插针的那一下2.1 一帧画面在 D3D9 里的调用链D3D9 的一帧从逻辑上分为三步清空目标、提交场景、翻转显示。对应到 API 调用上就是 Clear、BeginScene、若干条 DrawIndexedPrimitive / DrawPrimitive最后 EndScene 收尾Present 把后台缓冲翻到前台。游戏每一帧都会完整走一遍这个循环哪怕场景里什么都没有几个标记性调用也一定存在。EndScene 之所以是“插针”的最佳位置是因为它位于游戏自己的绘制全部结束之后、Present 提交之前。在这个时间点上前台绘制已经全部写进后台缓冲你接着画任何东西都会被完整呈现在画面上且不会干扰游戏内部的绘制流程。而 Present 之后画面已经提交覆盖层若画在 Present 之后再响应就会出现闪跳。常见录制软件和调试工具都是在这一帧的缝隙里写自己的内容。注意一个细节游戏引擎普遍会把“计算”和“渲染”拆开EndScene 只是渲染线程的一个时间点。如果你的覆盖层需要展示逻辑层的实时数据这些数据必须在渲染线程外先算好EndScene 里只做读取和绘制。把这个边界守好后面很多问题都不会发生。2.2 三种 Hook 方式怎么选VTable、IAT 与内联 DetourD3D9 的接口是 COM 风格虚函数都走 vtable。所以“把 EndScene 换成我们的函数”在实现上有三条路。VTable Hook 是把设备对象虚表里对应项的函数指针替换成自己的函数。好处是只改内存数据不碰代码段调试直观适合快速原型坏处是容易被扫描校验而且游戏在切换全屏/窗口时通常会调用 Reset 重建设备和资源虚表指针换新后旧 Hook 会失效。IAT Hook 作用于 PE 文件的导入表只能替换从 DLL 导入的导出函数。但 EndScene 不是 d3d9.dll 的导出函数它只是虚方法所以 IAT 在这个场景里最多能钩住 Direct3DCreate9 这个入口。很多教程把 IAT 和 D3D Hook 混着提实际上你只会用它做入口拦截真正的 EndScene 还是得走 vtable 或 Detour。内联 DetourMinHook 就是这一类修改函数头部指令插入一跳跳转到自己的函数。MinHook 内部把被覆盖的指令搬到蹦床trampoline里保证原函数逻辑完整。好处是不关心对象和虚表直接钉在 d3d9.dll 里的真实函数地址上Reset 之后依然有效缺点是修改了代码段指令对齐和线程同步都得处理——MinHook 替你做了大部分但你需要理解它为什么能工作。x64 下给 JMP 制造空间不容易MinHook 的做法是把头部指令搬走后在原地址写入 JMP相对地址原函数其余部分保持不动。蹦床里先执行搬走的指令再跳回原函数跳过被搬走的部分。如果之后你想自己实现一遍最容易翻车的就是搬走的指令条数对齐一条指令被砍一半会导致非法指令崩溃。所以绝大多数人直接用 MinHook我的建议也是别重复造轮子。Hook 方式修改目标实现难度Reset 后兼容主要风险VTable对象虚表项低设备重建后失效易被扫描IATPE 导入表中不受影响只钩入口钩不到虚方法内联 Detour函数头字节高MinHook 封装后中依然有效指令对齐 / 线程竞态实际项目里游戏工具和调试器大多用内联 Detour因为 Reset 带来的设备重建太常见了VTable 方案在窗口模式切换后要重新约一次虚表处理起来很烦。MinHook 这类库已经算 D3D Hook 的事实标准后面代码也基于它。2.3 用 C 打印设备 vtable自己验证 EndScene 偏移写代码前先说清楚偏移怎么来。把 IDirect3DDevice9 头文件里的接口定义从 QueryInterface 往下数到 EndScene 是第 37 个方法下标从 0 开始算。这个数字我用了好几年但每次换 SDK 版本还是会核对一遍因为不同 SDK 的头文件声明顺序理论上可能调整。下面这段探针代码可以独立跑创建一个小窗口取出设备打印 vtable 里对应位置的函数地址。#include d3d9.h #include cstdio #include Windows.h int main() { HWND hwnd CreateWindowA(STATIC, d3d9 probe, WS_OVERLAPPED, 0, 0, 640, 480, nullptr, nullptr, GetModuleHandleA(nullptr), nullptr); IDirect3D9* d3d9 Direct3DCreate9(D3D_SDK_VERSION); if (!d3d9) return 1; D3DPRESENT_PARAMETERS pp{}; pp.Windowed TRUE; pp.SwapEffect D3DSWAPEFFECT_DISCARD; pp.BackBufferFormat D3DFMT_UNKNOWN; pp.BackBufferWidth 640; pp.BackBufferHeight 480; IDirect3DDevice9* device nullptr; HRESULT hr d3d9-CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, pp, device); if (FAILED(hr)) return 1; // COM 对象头部 8 字节是 vtable 指针这里顺便复习一下 C 指针用法 // 把 device 强转成 void***, 再解引用一次, 拿到完整的虚函数表 void** vtbl *reinterpret_castvoid***(device); printf(EndScene[37] %p\n, vtbl[37]); printf(Present[15] %p\n, vtbl[15]); device-Release(); d3d9-Release(); return 0; }逻辑说明D3D9 的 device 是一个 COM 对象内存最开始位置存放 vtable 指针这是所有 COM 对象的共同布局。reinterpret_castvoid*** 把 device 视为指向指针的指针一次解引用便得到虚函数表。vtbl[37] 就是 EndScene 的真实地址打印出来可以直接拿去和 MinHook 的 Hook 目标作对比。如果你打印出来是 0x00000000 或者进程直接崩溃大概率是索引数错了回到 d3d9.h 里从 QueryInterface 重新数别凭记忆写死。参数说明D3DDEVTYPE_HAL 使用硬件光栅化是所有游戏实际使用的设备类型D3DCREATE_SOFTWARE_VERTEXPROCESSING 是纯软件顶点处理能绕开老显卡驱动不支持硬件顶点处理导致 CreateDevice 失败的情况探针程序够用。D3DFMT_UNKNOWN 表示后台缓冲格式跟随窗口省去遍历格式列表的麻烦。这段代码要在链接参数里加上 d3d9.lib。3. 用 C 和 MinHook 跑通最小 EndScene Hook从环境到第一行绘制3.1 环境准备MinHook 引入与 D3D9 头文件来源Windows SDK 自带 d3d9.h 和 d3d9.lib不需要再装老 DXSDK。很多老教程会让你去装 DirectX SDK June 2010我建议直接跳过——它跟新版 Visual Studio 的 CRT 头文件冲突是出了名的编译时一堆重定义报错纯属自找麻烦。MinHook 是开源的 C/C 库需要自己编译成 lib。最省事的路是从仓库 clone 下来用 VS 打开解决方案编译 x86 和 x64 两个 Release 版本链接期用哪个取决于目标进程位数。编译产物里两个文件要记牢MinHook.lib 用于链接MinHook.h 用于包含头文件。如果你的工程嫌手编麻烦用 vcpkg 安装 minhook 也一样本质是同一份代码不引入额外运行时依赖。做 C 游戏项目时这种小依赖向来是能少则少手动加源码是最可控的方式。3.2 最小 Hook 链先钩 Direct3DCreate9 再钩 CreateDevice直接在 DllMain 里拿设备是拿不到的因为 Hook DLL 加载时游戏可能还没创建 D3D9 设备。标准做法是三级递进钩住导出函数 Direct3DCreate9在它返回后立刻钩住 IDirect3D9 对象的 CreateDevice等游戏调用 CreateDevice 创建设备再钩住 EndScene。这里套用上一章的虚表索引IDirect3D9::CreateDevice 在 vtable[16]IDirect3DDevice9::EndScene 在 vtable[37]。代码拆成三段方便对照排查。#include d3d9.h #include MinHook.h #include Windows.h #pragma comment(lib, d3d9.lib) #pragma comment(lib, MinHook.lib) typedef IDirect3D9* (WINAPI* Direct3DCreate9_t)(UINT SDKVersion); typedef HRESULT (WINAPI* CreateDevice_t)( IDirect3D9*, UINT, D3DDEVTYPE, HWND, DWORD, D3DPRESENT_PARAMETERS*, IDirect3DDevice9**); typedef HRESULT (WINAPI* EndScene_t)(IDirect3DDevice9*); Direct3DCreate9_t TrueDirect3DCreate9 nullptr; CreateDevice_t TrueCreateDevice nullptr; EndScene_t TrueEndScene nullptr; IDirect3DDevice9* g_device nullptr;函数指针分别保存原始函数地址后面每次调用都走这些指针画完覆盖层后把调用交还给原函数。HRESULT WINAPI HookedEndScene(IDirect3DDevice9* device) { DrawOverlay(device); // 先画自己的内容 return TrueEndScene(device); // 再让原函数收尾 } HRESULT WINAPI HookedCreateDevice( IDirect3D9* self, UINT adapter, D3DDEVTYPE type, HWND focus, DWORD flags, D3DPRESENT_PARAMETERS* pp, IDirect3DDevice9** out) { HRESULT hr TrueCreateDevice(self, adapter, type, focus, flags, pp, out); if (SUCCEEDED(hr) *out) { g_device *out; // 保存设备指针供绘制函数使用 void** vtbl *reinterpret_castvoid***(g_device); MH_CreateHook(vtbl[37], HookedEndScene, (void**)TrueEndScene); MH_EnableHook(vtbl[37]); } return hr; }HookedCreateDevice 的注意点一定先调用原始函数拿到设备再去做二次 Hook。如果先安装 EndScene 钩子再调原 CreateDevice游戏创建出来的第一个设备反而可能绕过钩子造成时好时坏的诡异状态。IDirect3D9* WINAPI HookedDirect3DCreate9(UINT version) { IDirect3D9* d3d9 TrueDirect3DCreate9(version); if (d3d9) { void** vtbl *reinterpret_castvoid***(d3d9); MH_CreateHook(vtbl[16], HookedCreateDevice, (void**)TrueCreateDevice); MH_EnableHook(vtbl[16]); } return d3d9; } BOOL APIENTRY DllMain(HMODULE mod, DWORD reason, LPVOID) { if (reason DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(mod); // 避免库线程通知带来的死锁 MH_Initialize(); HMODULE d3d9 LoadLibraryA(d3d9.dll); // 主动加载, 避免 GetModuleHandle 返回空 void* fn (void*)GetProcAddress(d3d9, Direct3DCreate9); MH_CreateHook(fn, HookedDirect3DCreate9, (void**)TrueDirect3DCreate9); MH_EnableHook(fn); } return TRUE; }为什么第一段要用 LoadLibraryA 主动把 d3d9.dll 拉进进程Hook DLL 被加载时目标进程未必已经加载 d3d9.dllGetModuleHandleA 只查“已加载”的模块查不到返回 nullGetProcAddress 跟着崩溃。虽然多数游戏启动就会加载 d3d9但不要赌这个。第二段里 DllMain 只做环境初始化和入口 Hook。MH_Initialize、LoadLibrary、GetProcAddress 这类操作在加载器锁内都可能卡住如果目标进程同时有其他 DLL 在初始化死锁概率不低。严谨写法是把初始化丢到独立线程DllMain 里 CreateThread 处理这里为了演示逻辑清晰保留了直接调用实际工程里建议改造。3.3 在 EndScene 里画一个十字形指示标记覆盖层绘制最直接的方式是自定义顶点加 DrawPrimitiveUP不需要创建顶点缓冲内存直接提交适合覆盖层这种少量图元。void DrawOverlay(IDirect3DDevice9* device) { D3DVIEWPORT9 vp{}; device-GetViewport(vp); struct Vertex { float x, y, z, rhw; DWORD color; }; const float cx vp.Width * 0.5f, cy vp.Height * 0.5f; Vertex verts[8] {}; // 水平线两条线段反向 verts[0] { cx - 40.f, cy, 0.f, 1.f, 0xFFFF0000 }; verts[1] { cx 40.f, cy, 0.f, 1.f, 0xFFFF0000 }; verts[2] { cx 40.f, cy, 0.f, 1.f, 0xFFFF0000 }; verts[3] { cx - 40.f, cy, 0.f, 1.f, 0xFFFF0000 }; // 垂直线两条线段反向 verts[4] { cx, cy - 40.f, 0.f, 1.f, 0xFFFF0000 }; verts[5] { cx, cy 40.f, 0.f, 1.f, 0xFFFF0000 }; verts[6] { cx, cy 40.f, 0.f, 1.f, 0xFFFF0000 }; verts[7] { cx, cy - 40.f, 0.f, 1.f, 0xFFFF0000 }; device-SetFVF(D3DFVF_XYZRHW | D3DFVF_DIFFUSE); device-SetRenderState(D3DRS_CULLMODE, D3DCULL_NONE); device-SetRenderState(D3DRS_LIGHTING, FALSE); device-SetRenderState(D3DRS_ZENABLE, FALSE); device-SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE); device-SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA); device-SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); device-DrawPrimitiveUP(D3DPT_LINELIST, 8, verts, sizeof(Vertex)); }逻辑说明八个顶点画出四条线段构成屏幕中央的十字形指示标记。颜色 0xFFFF0000 是不透明的红色想把整个标记变成半透明把最高字节的 FF 改小同时开启 alpha 混合即可。FVF 声明了顶点格式——位置 (x,y,z,rhw) 加颜色这是覆盖层绘制最常见的顶点格式rhw 置 1 表示使用屏幕坐标模式不需要投影变换。参数说明DrawPrimitiveUP 的最后一个参数是顶点步长 sizeof(Vertex)编译器按默认对齐规则填充到 20 字节16 字节位置 4 字节颜色这里没有隐式 padding。如果你以后给 Vertex 加字段必须同步更新步长否则 D3D 读到的顶点数据会错位画出来的形状完全不是预期。渲染状态的细节ZENABLE 必须设成 FALSE。游戏场景会把深度写入深度缓冲你的覆盖层坐标深度是 0如果不关深度测试只要场景里有物体深度更小你的线就会被挡掉一部分表现成“时隐时现”。4. D3D Hook 的必调参数分辨率、DPI、渲染状态与多线程同步4.1 分辨率与 DPI 修正为什么画出来的框总对不上GetViewport 必须每次实时调用而不是缓存在外面。游戏允许玩家运行中拖拽窗口或改分辨率之前缓存的坐标全部失效。按 vp.Width 和 vp.Height 比例算相对位置就能自动适配窗口变化。这也是很多 Demo 一跑就崩的隐藏原因示例代码里把视口尺寸缓存在全局变量里只在设备创建时读一次。DPI 是个更容易被忽略的坑。Windows 10 1703 以后如果进程没有声明 DPI aware系统会对窗口产生虚拟化缩放GetViewport 返回的逻辑分辨率与真实像素不一致画上去的框会整体偏移。症状非常典型覆盖层的位置跟鼠标光标错位分辨率越高偏得越远重装显卡驱动没有任何作用。解决方式是在进程最早入口调用 SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)或者提供 manifest 声明 per-monitor DPI awareness。两种方式都必须在窗口创建前完成调用晚了系统已按虚拟化定好了比例函数会返回 E_ACCESSDENIED。如果是注入到别人的游戏进程DPI 设置要在你 Hook 线程里尽早执行游戏自己的 manifest 往往不会声明这个东西。4.2 渲染状态复位每组覆盖层绘制前都重设被同事问过“为什么我画完一半下一帧整个画面色调不对”十有八九是渲染状态被改了没恢复。EndScene 时机位于游戏绘制之后游戏把光照、混合、深度测试设置成适合它自己场景的组合覆盖层插进来时如果沿用这些状态会出现各种预期外的效果线条被剔除、颜色被光照改掉、深度测试挡住部分图元。建议每次绘制覆盖层前把关键状态全部显式设置一次。一个帧循环里覆盖层数量多也没什么D3D9 状态设置的 CPU 开销基本可以忽略。渲染状态推荐值原因D3DRS_ZENABLEFALSE关闭深度测试避免覆盖层被场景深度遮挡D3DRS_CULLMODED3DCULL_NONE取消背面剔除单面线条不受影响D3DRS_LIGHTINGFALSE顶点色跟随光源不关闭会被光照修改D3DRS_ALPHABLENDENABLETRUE开启 alpha 混合才能做半透明覆盖层D3DRS_SRCBLENDD3DBLEND_SRCALPHA前景 alpha 作为混合因子D3DRS_DESTBLENDD3DBLEND_INVSRCALPHA背景按 1-alpha 混合这里有个反直觉的结论EndScene 绘制在游戏画面之后你不恢复状态其实不会影响游戏本帧的画面因为这一帧不会有后续绘制了。但如果游戏在 EndScene 之后还做后期处理比如色阶、泛光被改掉的状态会顺着渲染管线继续作用。规范做法是覆盖层 DrawPrimitiveUP 之后把状态恢复成你进入时保存的那组在 HookedEndScene 入口先 CaptureState绘制完 RestoreStateD3D9 里成本很低。老教程通常省略这一步遇到色调异常时第一个该怀疑的就是它。4.3 多线程同步逻辑线程与渲染线程的覆盖层数据交接Hook 本身运行在游戏渲染线程而数据往往来自逻辑线程比如网络回调、文件监听、UI 操作。直接在回调里改共享变量渲染线程读取一定会遇到竞态问题。表现是数据一半更新一半没更新绘制出的图元撕裂甚至偶发踩内存崩溃。不要在 EndScene 里做任何耗时的加锁操作。很多人图省事在 EndScene 里直接读共享 map 或 vector锁直接加在绘制循环里结果帧率骤降。正确做法是把数据的生产和消费解耦。std::mutex g_mutex; std::vectorOverlayItem g_pending; // 逻辑线程写入 std::vectorOverlayItem g_draw; // 渲染线程消费 void PushOverlayItem(const OverlayItem item) { std::lock_guardstd::mutex lock(g_mutex); g_pending.push_back(item); } // 在 HookedEndScene 里调用 void DrawOverlay(IDirect3DDevice9* device) { { std::lock_guardstd::mutex lock(g_mutex); g_draw.swap(g_pending); // 交换而不是拷贝 } for (const auto item : g_draw) { // 真正绘制在这里, 此时已无锁 } g_draw.clear(); }逻辑说明逻辑线程把要画的东西塞进 g_pending渲染线程在每次 EndScene 时把 g_pending 整个换出来swap 是 O(1) 操作锁只在交换那一瞬持有绘制循环里完全没有锁。这样即使逻辑线程高频推送数据渲染线程也只是每帧消费最新一批不会堆积旧帧数据。容易被忽略的坑swap 换出来的 g_draw 里残留上一帧数据在下一帧循环开头 clear 掉清的是已经消费完的旧数据不影响逻辑线程继续往里写。如果忘记 clear覆盖层会越画越多最后整屏都是旧图元的累积。5. 避坑D3D Hook 失效与崩溃的五个高发原因5.1 vtable 编号数错一进就崩现象Hook 装好后目标进程立即退出或者进程还在但没有任何绘制效果连日志都打不出来。原因把 IDirect3D9 和 IDirect3DDevice9 的 vtable 混用或者 SDK 头文件版本不同导致编号不一致。解决先用 2.3 的探针程序打一次 vtbl[37]确认打印出的地址落在 d3d9.dll 的模块地址区间内——模块基址往下数几个 MB 的范围而不是一个完全离谱的地址。这个验证 30 秒做完能省一整天的排查时间。5.2 DllMain 里做初始化触发加载器锁死锁现象DLL 注入后进程挂死约半分钟后弹“已停止工作”。原因DllMain 里 LoadLibrary、MH_Initialize、创建窗口碰到其他模块的加载锁而系统当时正持有加载器锁双向等待形成死锁。解决DllMain 里只做最轻量的事用 CreateThread 启动初始化线程所有 Hook 安装放到新线程入口。这是 MinHook 官方 FAQ 里的标准做法别存侥幸。5.3 全屏 / AltTab 切换后设备资源全部失效现象从窗口切全屏或最小化再恢复后覆盖层消失随后画面冻结或纹理错乱。原因D3D9 设备在切换显示模式时会进入 Lost 状态后台缓冲、字体对象、顶点缓冲全部失效。但 Hook 的函数指针装在函数地址上不受影响所以表现是“钩子还在资源没了”。解决在 EndScene 里检查设备状态按状态分派重建流程。HRESULT state device-TestCooperativeLevel(); if (state D3DERR_DEVICELOST) { // 释放所有 D3D 资源比如字体和表面 // 这一帧不画覆盖层直接交还给原函数 return TrueEndScene(device); } else if (state D3DERR_DEVICENOTRESET) { // 重建设备参数沿用创建设备时的 D3DPRESENT_PARAMETERS device-Reset(g_pp); // 重新创建字体和表面 }注意D3DERR_DEVICELOST 阶段不能调用 Reset必须等系统给出 D3DERR_DEVICENOTRESET 才能重建顺序反了会直接报无效调用。同时设备丢失期间直接丢帧不绘制不要尝试恢复任何资源。这里也是老代码里最容易出现崩溃的地方因为设备丢失时你手里的所有表面都已失效绘图会踩到已释放的内存。5.4 目标机器缺 VC 运行库Hook DLL 加载失败现象自己开发机上一切正常换一台机器后注入无反应事件查看器里报找不到 msvcp140.dll或者弹出错误对话框。原因项目用 C 编译的 Hook DLL 默认链接动态运行库目标机器没有装 Microsoft Visual C Redistributable。解决把对应架构的 vc_redist.x64.exe 放进部署包或者在项目属性里把运行库改成 /MT 静态链接。对工具类 DLL 我一般直接 /MT少一台机器就少一个现场。5.5 在 EndScene 里跑了重逻辑帧率波动剧烈现象游戏帧率从稳定数值掉到一半以下而且忽高忽低持续越久越卡。原因EndScene 每一帧都会被调用任何耗时的日志、文件读写、字符串格式化、网络同步写进去都会被放大成整帧的性能瓶颈。解决把重逻辑放进队列或独立线程EndScene 只消费已经画好的数据。验证方法用 QueryPerformanceCounter 在 Hook 入口和原函数返回处各打一个点统计平均耗时单帧超过 1ms 的逻辑逐个移出。6. 从 Demo 到可用工具热更新开关与三分钟验证法一个能落地的 Hook 工具至少需要两个东西随时能关掉的开关和一个不依赖调试器的验证手段。热更新开关用导出的函数做最省事。在 Hook DLL 里维护一个原子布尔量暴露导出函数给调用方切换就不用每次改代码重新编译注入。#include atomic std::atomicbool g_draw_enabled{true}; extern C __declspec(dllexport) void SetDrawEnabled(bool enabled) { g_draw_enabled.store(enabled, std::memory_order_relaxed); }调用方通过 GetProcAddress 按名字找到这个导出函数运行时来回切换覆盖层立即消失或出现。这个开关还能用来做问题定位关闭后覆盖层消失问题就出在绘制代码里关闭后依旧崩溃问题就在 Hook 链本身排查范围直接缩小一半。验证第一招断点计数。在 HookedEndScene 第一行下断点附加到目标进程只观察命中次数不单步。十秒钟命中几百次说明钩子在稳定触发只命中一次就停说明 EndScene 不是每帧都被调用往设备丢失方向查。验证第二招窗口与全屏切换。窗口模式下把目标窗口拖到不同显示器确认覆盖层相对位置没有偏移再切一次全屏确认没有触发崩溃。这两轮覆盖了现场大多数问题。验证第三招帧开销对比。用 QueryPerformanceCounter 在 Hook 前后各测一轮相同场景帧时间上升超过 0.5ms 就该回去看 5.5 条。我自己的习惯是任何 D3D Hook 改动后先保持一个空的 EndScene 钩子跑十分钟确认帧率和内存没异常再逐步加绘制逻辑。这套流程看起来笨但每次都能把问题限定在“新加的代码”而不是“Hook 本身坏了”。D3D Hook 的技术坑就这些原理通了后面就是经验和耐心希望帮到你。本文还有配套的精品资源点击获取
