简介：面向需要深入Direct3D底层渲染控制与Hook技术研究的开发者，提供一份精简的C++源文件，呈现D3DHook的完整实现思路，能够通过API钩子与内存钩子方式，对多个DirectX版本的渲染管线进行统一拦截与功能扩展，适用于游戏修改、性能分析、画面捕捉、渲染调试等典型场景。压缩包仅含1个cpp文件，大小仅2KB，内容聚焦于核心拦截逻辑，包含DLL注入、API地址替换、在设备创建、交换链初始化与绘制调用等关键节点插入自定义代码的跨版本处理思路，体量虽小但便于逐行研读和二次开发。目前已有616人学习下载，对于想快速理解D3DHook“通杀”机制，或需要在不同DirectX版本中实现渲染干预的开发者，这份源码提供了一个轻量且直接的技术起点。通过该代码，可重点掌握Direct3D API函数指针替换与内存Hook的差异，以及如何在保持向后兼容性的前提下适配不同版本特性，并借此扩展出更多画面自定义与性能分析功能。
1. 为什么“D3Dhook通杀所有DirectX版本”不靠魔法，靠一张接口地图
只要做过一版带渲染覆盖层的工具，就能体会面对 DirectX 版本分裂时的无力感。D3D9 时代大家挂着 IDirect3DDevice9 的 EndScene 就能画菜单，D3D11 里 EndScene 直接消失了，D3D12 更过分，连“立即上下文”都成历史名词，绘制变成了命令列表和命令队列之间的异步协作。所谓 D3Dhook 通杀所有 DirectX 版本，并不是真的准备用一套指令去匹配所有 API，而是要在运行时识别当前进程用的是哪一版 D3D，再把钩子挂到该版本对应的“最终出图点”上。本文从 COM 对象和虚函数表切入，写一个能自动识别版本的 D3Dhook 分发器，覆盖 D3D9、D3D10、D3D11、D3D12 的挂接差异，并给出多版本通用的验证方法。读者最好有 Windows 下 C++ COM 编程经验，或至少知道 MinHook、Detours 这层函数级 Hook 工具，不然直接抄代码容易翻车。
2. 版本差异的地基：从 D3D9 的 Device 到 D3D12 的 CommandQueue
2.1 每个版本把“渲染能力”放在哪个 COM 对象上
D3D 的 API 是围绕 COM 接口组织的，所以 D3Dhook 的本质就是修改 COM 对象虚函数表的跳转目标。但问题在于，不同版本把渲染函数放在不同接口上，只认一个接口必然顾此失彼。
- D3D9： IDirect3DDevice9 是绝对核心。CreateDevice 之后，所有资源绑定、绘制调用、Present 都通过这个 Device 调用。EndScene 和 Present 在虚表里的位置很固定，D3D9 时代大量覆盖层工具都挂在这里。
- D3D10：接口变成 ID3D10Device，绘制方法仍在 Device 上，但 DXGI 已经开始独立管理交换链。IDXGISwapChain::Present 逐渐成为比 EndScene 更重要的挂接点。
- D3D11：设备拆成 ID3D11Device 和 ID3D11DeviceContext 两个角色。前者管资源创建，后者管绘制状态与 Draw 调用。CreateDeferredContext 还会产生多个 Deferred Context，普通用户看到的是 ID3D11DeviceContext，但线程模型比 D3D9 复杂得多。
- D3D12：彻底换思路。ID3D12GraphicsCommandList 只负责记录指令，要等 ID3D12CommandQueue::ExecuteCommandLists 才真正把绘制提交到 GPU。单独钩 DrawIndexed 只能看到记录动作，看不到实际执行。
换句话说，“通杀”如果只是把所有版本的绘制函数都钩一遍，会漏掉 D3D12 最关键的一环——命令队列。所以先接受一个结论：跨版本时不能靠猜函数索引，必须按版本把钩子安放到语义等价的那一层，D3D9 放 Device，D3D11 放 DeviceContext，D3D12 放 CommandQueue，最后再靠 DXGI Present 统一兜底。
2.2 为何 EndScene、Present、ExecuteCommandLists 是“通杀”的锚点
要做“所有 DirectX 版本都能生效”的 hook，最稳定的锚点不是绘制函数，而是“每一帧结束、画面即将提交”的那几个调用。D3D9 里是 EndScene 和 Present，D3D10、D3D11 里是 IDXGISwapChain::Present，D3D12 里 Present 依然存在，DXGI 对三层版本共用一套接口。
这也解释了为什么市面上很多 D3Dhook 项目都把 Present 作为最后兜底。它的调用频率和刷新率绑定，只要能稳定拿到 IDXGISwapChain 指针，无论底层是 D3D10 还是 D3D12，都能在最接近最终画面的位置插入一段渲染代码。绘制函数的钩子则用来做更深层的性能分析和修改石，但它不承担“通杀”任务。
表 2-1 给出各版本的语义等价关系，这是后续代码实现时选索引的出发点：
| DirectX 版本 | “绘制提交到 GPU”的入口 | “画面交给显示”的入口 | 建议最小 hook 集 |
|---|---|---|---|
| D3D9 | IDirect3DDevice9::DrawIndexedPrimitive | IDirect3DDevice9::Present | Present + EndScene |
| D3D10 | ID3D10Device::DrawIndexed | IDXGISwapChain::Present | IDXGISwapChain::Present |
| D3D11 | ID3D11DeviceContext::DrawIndexed | IDXGISwapChain::Present | DrawIndexed + Present |
| D3D12 | ID3D12CommandQueue::ExecuteCommandLists | IDXGISwapChain::Present | ExecuteCommandLists + Present |
这套锚点关系不是靠查 SDK 文档就能拍板，IDE 里看到的接口方法顺序也只代表头文件顺序，运行时虚表索引可能因 DLL 版本偏移。所以严谨的 D3Dhook 实现要把“枚举接口、确认版本、按偏移取地址”作为固定链路，不能把索引写死在代码里。
2.3 为什么统一用 IUnknown 遍历而不是直接依赖 d3d9.h
我见过不少刚上手的人直接链入 d3d9.lib、d3d11.lib，再用各自 SDK 里的类型判断版本。这在纯 D3D9 工程里没问题，但要做全版本兼容，就不该在编译期写死任何一个 D3D 头文件。原因有两个：第一，D3D12 和 D3D9 的接口继承关系完全不同，无法用 C++ 的 static_cast 安全互转；第二，目标进程可能只加载了其中一个 DLL，链接期把 d3d12.lib 拉进来会让模块依赖变大，容易被系统的 DLL 搜序机制影响。
所以更可靠的路数是以 IUnknown 作为入口，用 QueryInterface 或 GetDevice 方法探测对象种类。拿到一个未知 COM 指针后，先询问它是 ID3D12Device 还是 ID3D11Device，再按已知 IID 逐个转换。这个方法在老版本和新版本之间都是安全的，因为每个对象都至少支持 IUnknown。这也是后面要写的“版本感知分发器”的核心逻辑。
3. 实现版本感知 D3Dhook：最小分发器加函数地址替换
3.1 用 QueryInterface 识别 D3D9 / D3D11 / D3D12 的最小代码
先写一个纯识别模块，输入 IUnknown 指针，输出识别的 D3D 版本。这个模块不关心怎么把字体画到屏幕上，也不关心帧数据如何采集，只承担一件事：在起点把版本搞清楚。
enum class D3DVersion { Unknown, D3D9, D3D10, D3D11, D3D12 }; D3DVersion IdentifyD3DVersion(IUnknown* pObject) { if (pObject == nullptr) return D3DVersion::Unknown; ID3D12Device* pDevice12 = nullptr; if (SUCCEEDED(pObject->QueryInterface(__uuidof(ID3D12Device), (void**)&pDevice12))) { pDevice12->Release(); return D3DVersion::D3D12; } ID3D11Device* pDevice11 = nullptr; if (SUCCEEDED(pObject->QueryInterface(__uuidof(ID3D11Device), (void**)&pDevice11))) { pDevice11->Release(); return D3DVersion::D3D11; } ID3D10Device* pDevice10 = nullptr; if (SUCCEEDED(pObject->QueryInterface(__uuidof(ID3D10Device), (void**)&pDevice10))) { pDevice10->Release(); return D3DVersion::D3D10; } IDirect3DDevice9* pDevice9 = nullptr; if (SUCCEEDED(pObject->QueryInterface(__uuidof(IDirect3DDevice9), (void**)&pDevice9))) { pDevice9->Release(); return D3DVersion::D3D9; } return D3DVersion::Unknown; }这段代码的逻辑是“高版本优先”：先问对象是不是 D3D12，再往下问 D3D11、D3D10、D3D9。优先检查高版本的理由是，部分新的显卡驱动在兼容模式里会让 D3D11 设备也响应某些旧接口查询，从新到旧可以避免把 D3D11 设备误判成 D3D9。每个 QueryInterface 成功后必须立刻 Release，否则外部引用计数会被错误抬高，导致对象无法正常销毁。识别完成后返回枚举值，后面挂接函数时只对这个枚举值做分支。
3.2 虚表替换的落点：挂 Present 而不是挂全部绘制方法
对“通杀”来说，全版本绘制函数的虚表索引差异极大，且随驱动和 SDK 版本漂移。相比之下，IDXGISwapChain 的 Present 是所有版本共同出现的接口，挂接点统一，代码也更好维护。下面用 MinHook 挂 IDXGISwapChain::Present，这是最小可行实现。
#include <MinHook.h> #include <dxgi.h> typedef HRESULT (STDMETHODCALLTYPE* Present_t)( IDXGISwapChain*, UINT, UINT); Present_t OriginalPresent = nullptr; HRESULT STDMETHODCALLTYPE PresentHook( IDXGISwapChain* pSwapChain, UINT SyncInterval, UINT Flags) { // 每个挂接点都应该先拿到调用链上真实发生的参数 // SyncInterval 控制垂直同步，遍历时记录一次即可 g_FrameCount.fetch_add(1, std::memory_order_relaxed); return OriginalPresent(pSwapChain, SyncInterval, Flags); } void InitializeSwapChainHook(IDXGISwapChain* pSwapChain) { void** vtable = *reinterpret_cast<void***>(pSwapChain); // 用指针数组的第 8 项：IDXGISwapChain 的 Present // 这个索引在 DXGI 中跨 D3D10/D3D11/D3D12 一致 auto* pPresent = reinterpret_cast<Present_t>(vtable[8]); MH_STATUS status = MH_CreateHook(pPresent, &PresentHook, reinterpret_cast<void**>(&OriginalPresent)); if (status == MH_OK) { MH_EnableHook(pPresent); } }要注意两个参数的含义，SyncInterval 决定是否同步垂直刷新：0 表示不等待垂直同步，立即呈现，适合性能测试；1 表示每个 VBlank 呈现一帧，功耗更低。Flags 里最常用的是 DXGI_PRESENT_TEST，如果目标是做渲染采集，这个调用其实不真正呈现，不应当计入帧计数。如果只录视频，可以忽略带 DXGI_PRESENT_TEST 的调用，否则统计到的帧率会和显示帧率对不上。
另一个重要点是，把所有版本的 Present 都挂成同一个回调，是一个“统一入口”思路。回调内部只做轻量统计和指令转发，任何绘制插入逻辑另起线程处理，避免在 Present 里阻塞太久导致掉帧和系统 DWM 卡顿。
3.3 在 D3D12 上扩展钩子到 ExecuteCommandLists
Present 钩子足够让覆盖层显示，但它拿不到 D3D12 的绘制命令。若要读取命令列表或统计 Draw Call，需要在 D3D12 版本上再挂 ID3D12CommandQueue::ExecuteCommandLists。
typedef void (STDMETHODCALLTYPE* ExecuteCommandLists_t)( ID3D12CommandQueue*, UINT, ID3D12CommandList**); ExecuteCommandLists_t OriginalExecuteCommandLists = nullptr; void STDMETHODCALLTYPE ExecuteCommandListsHook( ID3D12CommandQueue* pQueue, UINT NumCommandLists, ID3D12CommandList** ppCommandLists) { g_ExecutedCommandLists.fetch_add(NumCommandLists, std::memory_order_relaxed); // 对每个命令列表可以继续往下检查类型 // 但不能在这里直接读取绘制参数，D3D12 命令列表钱的 GPU 状态不可预测 OriginalExecuteCommandLists(pQueue, NumCommandLists, ppCommandLists); }这段代码只是为了“知道提交了几条命令列表”，不能直接推断 Draw Call 次数。D3D12 命令列表可能包含 Bundle，也可能由多个线程各自记录，真正要想每个 Draw 事件都拿到，需要继续遍历 ID3D12GraphicsCommandList 的虚表和私有内存布局。那部分接口不稳定，所以做框架级 D3Dhook 时，一般把 ExecuteCommandLists 作为统计锚点，不再向下深入。
Hook 安装时机也是个问题，ID3D12CommandQueue 通常不是由用户直接创建，而是从 ID3D12Device::CreateCommandQueue 拿到的。常见做法是同时钩住 CreateCommandQueue，创建成功后立刻安装 ExecuteCommandLists 钩子，才能做到“所有版本通杀”而不漏 D3D12。
4. 参数对照与踩坑记录：为什么你的 D3Dhook 一挂就黑屏
4.1 每个钩子函数必须保持原调用约定和返回值
COM 方法使用 __stdcall 调用约定，函数的第一个参数是 this 指针。如果替换函数声明成普通 C++ 成员或错误调用约定，栈不平衡会直接导致进程崩溃或黑屏。MinHook 内部已经处理了跳板跳转，但函数签名必须和原函数严格一致。
表 4-1 是三个最容易写错的原型，可直接对照检查：
| 接口方法 | 函数签名关键点 |
|---|---|
| IDXGISwapChain::Present | 两个参数：SyncInterval(UINT)、Flags(UINT)，返回 HRESULT |
| ID3D11DeviceContext::DrawIndexed | 三个参数：IndexCount、StartIndexLocation、BaseVertexLocation |
| ID3D12CommandQueue::ExecuteCommandLists | 三个参数：NumCommandLists、ppCommandLists，返回 void |
很多人在写 D3D11 的 DrawIndexed 钩子时，少写一个参数，结果调用原函数后顶点数据乱了，画面出现整屏噪点。这类问题不会立即崩溃，但特别难查。我的习惯是每个版本原型写完后，先用static_assert(sizeof(...))或编译期函数签名检查工具对一遍，再挂接。
4.2 多线程与重入保护：别让统计代码成为新的瓶颈
DirectX 的 Present 和 Draw 调用不一定总在主线程。D3D11 的 Deferred Context 可以在 worker 线程记录命令，D3D12 更是明确支持多线程命令列表录制。如果你的 D3Dhook 在回调里使用了非线程安全的容器，比如 std::vector 直接 push_back，几帧之后就会访问已损坏的内存。
class FrameStats { public: static void OnPresent() { // 使用原子操作，避免锁竞争影响渲染线程 presentCount.fetch_add(1, std::memory_order_relaxed); lastCallThreadId = GetCurrentThreadId(); } private: static inline std::atomic<uint64_t> presentCount{0}; static inline DWORD lastCallThreadId = 0; };线程局部存储也是常见的选择，每个渲染线程维护独立计数，最后汇总。不过要提防重入：有些应用会在 Present 回调里再调用 Present，比如在 Present 过程中做转场动画，遇到这种情况会无限递归。解决办法是加一个 TLS 标记，进入钩子时检查标记，发现正处于同线程回调中就跳过统计直接调用原函数。
4.3 交换链隔离：不要被“多交换链”骗了
很多程序会创建不止一个交换链。游戏启动时会先创建一个后备缓冲用于载入画面，进入主场景后再创建一个新交换链。如果 D3Dhook 只在第一个交换链上装了 Present 钩子，进入主界面后计数器会停住。所以当 UseHook 库只保留单一指针时，它并不“通杀”。
void OnSwapChainCreated(IDXGISwapChain* pSwapChain) { // 每条交换链都应该单独挂一次 Present InitializeSwapChainHook(pSwapChain); g_SwapChainMap[pSwapChain] = true; }在设备创建阶段，通常能通过 IDXGIFactory::CreateSwapChain 或 CreateSwapChainForHwnd 拿到交换链。正确方案是钩住这些工厂函数，把所有新建交换链都纳入 hook 管理，而不是只认第一个。这也解释了为什么很多 hook 项目会同时拦截 DXGI 工厂创建函数和 D3D 设备创建函数，因为只有这个位置才能保证不漏。
4.4 x64 跳转的 32 位问题：MinHook 如何解决长跳转
x64 下直接写汇编跳转会面临 32 位相对偏移不够的问题，MinHook 的核心价值是把短跳转、绝对地址跳转、多字节补丁统一处理。但要注意的是，MinHook 不是所有函数都能完美处理，目标函数头如果非常短，或被其他 hook 占用，会返回 MH_ERROR_UNSUPPORTED_FUNCTION。
因此在实际工程里，我会在挂接失败时打点日志，并做一个降级策略：如果 Present 挂不上去，就尝试挂 EndScene；如果 EndScene 也没有，就退回只用 Detours 的 trampoline。判断通杀效果是否达成，不能只看某次挂接成功，而是要在日志里逐版本记录 MH_STATUS 返回值。这个细节，说出来不太显眼，但正是多版本兼容代码和一次性 demo 的分水岭。
5. 验证“通杀”的最优技巧：用 Present 计数验证所有版本都命中
真正要交付的 D3Dhook 模块，不能只在开发机上的一两个版本里跑通。最朴素的验证方式，是写一段自动化测试程序，创建真实的 D3D9、D3D11、D3D12 渲染窗口，各自独立硬合并时钟，比对 Present 计数器是否在持续递增。这比人工打开不同应用看画面正常要快得多，也能暴露“某个版本根本没被挂上”的问题。
计数器方案如下：把每次 Present 命中后的计数写到共享内存，测试进程每个 2 秒读取一次，并且记录“最后一次命中的线程 ID”“最近的 SyncInterval”。如果计数不增长，说明钩子没挂上或进程根本没有调用 Present；如果计数增长但线程 ID 在不同线程间跳，要考虑 IDXGISwapChain 是否天然支持多线程，钩子里的客户端代码必须做好线程安全。
验证技巧还有一招，专门对付“窗口最小化导致 Present 调用停止”的误判。测试用例不要只开一个全屏窗口，至少要包含一个窗口模式和最小化窗口的切换。最小化时 Present 可能被系统卡住，此时不能认为 D3Dhook 失效。我一般会在测试期间让窗口周期性离开和恢复最小化，确认恢复窗口后计数器能继续递增。
如果整套验证程序在 Windows 10 和 Windows 11 的软件适配层（WARP 设备）里都能通过，那基本上可以判断这套“D3Dhook 通杀所有 DirectX 版本”的目标已经达成。至于某些第三方启动器会加载多个 DXGI 副本导致重复挂接，那是另一个层面的问题，排查逻辑遵循同一条主线：计算同一交换链的 Present 调用次数是否大于等于原调用次数，若超量，检查是否存在二次挂接。
本文还有配套的精品资源，点击获取
