简介：面向C++开发者的D3D11 Hook实现源码，提供x86与x64双平台支持，适合需要深入理解DirectX 11渲染管线HOOK注入与拦截技术的读者。项目中包含注入器、DLL主模块及独立的hook工程，并集成BeaEngine反汇编库，便于实现地址解析与指令级控制。整个资源共84个文件，压缩后约4.35MB，主要类型包括C++源文件(h/cpp)、项目配置(vcxproj/sln)、依赖库(lib/inc)及少量Python脚本，其中BeaEngine相关头文件与导入库覆盖多种汇编语言接口，方便在自定义Hook方案中复用。已有2674人学习下载，证明了该源码的热度与参考价值。通过该压缩包，读者可以获得一整套可直接编译调试的D3D11 Hook框架，包含注入、DLL加载、Hook安装与恢复的完整流程，适合作为D3D11图形调试、功能增强或逆向分析方向的技术起点。由于包内带有Visual Studio工程文件与生成日志，也可以快速比对编译环境和排错过程，降低上手门槛。
1. 为什么又要聊D3D11 HOOK：它的生命力远比你想的长
聊到D3D11的Hook，很多人第一反应是“这玩意儿是不是过时了”？DirectX 12都出了这么多年，Vulkan也早就成熟，市面上新游戏也基本都跑在DX12或者更现代的图形API上。但现实情况是，存量市场里还有大量应用、游戏引擎、播放器、工业可视化软件停留在D3D11上。D3D11的Hook技术不仅没过时，反而因为接口稳定、文档丰富、社区案例多，成了图形编程、游戏辅助开发、性能分析工具和录屏软件里最常见的基础设施。
我自己最早接触D3D11 Hook，是因为要给一个老项目做画面叠加层，用来显示帧率和性能数据，当时试过直接改业务代码、用MFC的OnPaint、甚至用GDI建透明窗口，效果都拉胯。后来才发现，业界通用做法就是在Present这个函数上挂钩子，在显卡把后台缓冲提交给显示器之前，插入自己的绘制逻辑。这就是D3D11 Hook最基本的使用场景。
这里要说明一个方向问题：Hook本身是一项中性的工程手段。它广泛用在帧数显示、录屏工具（OBS为代表）、画质增强（Reshade、ENB这类）、辅助调试、性能剖析、无障碍功能等领域，都是正经用途。同时它也是一部分灰色软件的基础技术。本文只从图形编程和软件工程的角度拆解技术原理，不涉及也不支持任何违规用途。
这篇内容适合什么人看？如果你在做图形调试工具、想接Reshade这类后处理架构、或者单纯想把“如何拦截D3D11函数调用”这个经典问题彻底搞明白，那么这篇源码级拆解应该能帮你省至少一周的弯路。如果你是零基础，只要C++语法过关，跟着思路走也能把环境和注入框架搭起来。
2. 核心原理拆解：我们从哪里下手，才能稳、准、狠地Hook住D3D11
2.1 为什么选择Hook Present而不是其他方法
D3D11的渲染链路是这样的：应用创建ID3D11Device和ID3D11DeviceContext，创建交换链IDXGISwapChain，每帧调用Draw系列API绘制，最后调用IDXGISwapChain::Present把后台缓冲翻转到前台。Present是距离“画面真正显示出来”的最后一公里，在这里挂钩子有几个得天独厚的优势。
第一个优势是稳定。Present每一帧都会被调用，帧率多高它就调用多频繁，你不需要关心游戏内部逻辑，也不需要在几百个DrawCall之间找切入点，就是无脑在帧尾插入，这里绝不可能漏掉任何一帧。
第二个优势是能拿到完整的后台缓冲。Present的第一个参数就是交换链指针，通过它可以拿到当前的后台缓冲纹理（BackBuffer），意味着你可以在不干扰原始渲染流程的前提下，把一帧画面覆盖、叠加、分析、编码输出，这是录屏和后期特效的基础。
第三个优势是回调时机可控。Present执行到一半时，渲染管线已经基本走完，但还没有翻转，这时候往上下文上塞一些Overlay绘制，用户看起来就是游戏自带UI一样自然。
当然也有人选择Hook ID3D11DeviceContext::DrawIndexed，走“抓取渲染命令”的路线，那套方案更适合做透视类或遮挡剔除类工具，但从通用性和帧尾介入的角度讲，Present是性价比最高的切入点。
2.2 拿到设备指针：Hook的入场券
具体动手之前，你把DLL注入到目标进程里了，但你的第一件事是拿到IDXGISwapChain和ID3D11Device实例。这里有一个经典的工程障碍：绝大多数游戏在启动时创建设备，而我们的DLL是中途注入的，如何拿到已经存在的设备指针？
业内主流的解法有三种：
第一种是遍历窗口找到目标窗口句柄（HWND），然后调用DXGI的枚举接口，拿到与此窗口关联的交换链。这种方式对大多数全屏或窗口化游戏都有效，但在某些“无窗口”或者窗口名被隐藏的应用上会失灵。
第二种是Hook D3D11的创建函数，比如直接Hook d3d11.dll里的D3D11CreateDeviceAndSwapChain，在自己的实现里调用原函数，等原函数返回后把设备、上下文、交换链指针抄下来，再返回给调用者。这是一个比前者更精准的方案，我们在后面会实测。
第三种是用DXGI的调试层接口，创建一个幽灵Device来补抓工厂指针，再用工厂去枚举目标进程的SwapChain。这套办法比较绕，但适合Windowless目标。
从简洁和可控角度，我会优先给大家演示方案B：直接拦截创建函数，等原生创建函数返回后，拦截器里拿到的那几个指针就是游戏真正在用的设备、上下文和交换链，然后调用我们自己的初始化逻辑，把虚函数表换掉，达到Hook目的。
2.3 COM接口的虚函数表布局：理解VTBL才能动手
D3D11和设备相关的接口都是COM接口，COM接口说白了就是一个虚函数表指针（VTBL）加纯虚函数的打包体。Hook的本质就是替换虚函数表里的某个函数指针，让它指向我们自己的函数地址。
ID3D11Device继承自ID3D11DeviceChild，ID3D11DeviceChild又继承自IUnknown。IUnknown有三个方法：QueryInterface、AddRef、Release。所以，ID3D11Device的虚函数表布局里，偏移0是QueryInterface，偏移1是AddRef，偏移2是Release，偏移3开始才是D3D11自己的方法。
Present函数是IDXGISwapChain的虚函数，IDXGISwapChain继承自IDXGIObject，IDXGIObject继承自IUnknown，它的虚函数表索引是第8个（IUnknown占3个，IDXGIObject额外有SetPrivateData、SetPrivateDataInterface、GetPrivateData、GetParent，共4个，加上前面3个是7个，Present排在第8个索引位置，即索引7）。
同理，如果你想挂钩ID3D11DeviceContext里的DrawIndexed，就要算ID3D11DeviceContext自己的虚表布局，但从完整方案上讲，Presenter拿到的那个DeviceContext指针就够用了。
2.4 X86和X64的差异：一份代码怎么同时支持两个位数
D3D11 Hook在X86和X64下的调用约定差异是新手最容易摔跤的地方。X86下，默认的C语言调用约定是cdecl，COM方法用的是stdcall，参数从右往左压入栈中，意味着我们替换的函数必须采用和原函数完全一致的签名，否则参数错位、栈不平衡，直接就崩。
而在X64下，Windows统一使用Microsoft x64调用约定，前四个整数或指针参数分别放在RCX、RDX、R8、R9寄存器中，多余的参数压栈。这意味着同一个Hook函数，在32位和64位编译版本下，参数传递的物理通道完全不同，如果复用同一份纯C++写法，几乎一定会出问题。
好在现代Hook库已经把这些差异封装掉了。比较主流的选择是MinHook和Detours。
MinHook的API极其简洁，创建Hook、启用Hook、禁用Hook三步走，底层用的是Hotpatch或者跳转补丁，能自动处理X86/X64的指令修补和重定位，我们只需要提供一个“函数的替身”即可。我的示例代码就基于MinHook。
3. 完整源码层级拆解：从DLL入口到Hook生效，每一段代码都是干什么的
3.1 工程结构和编译环境准备
代码按“一个DLL + 一个注入器”的结构组织。注入器负责把DLL注入到目标进程，DLL被加载后由DllMain触发，执行挂钩逻辑，并且在每次Present时调用我们的自定义回调完成叠加绘制。
编译环境我用的是Visual Studio 2022，项目属性里注意几个点：
- C++语言标准：C++17
- 目标平台：分别编译Win32和x64两个配置
- 字符集：使用Unicode字符集
- 附加依赖库：d3d11.lib、dxgi.lib、d3dcompiler.lib（后两个在编译着色器时有用）
- 预处理器：单独维护
_X86_和_AMD64_宏，确保代码可以按位数条件编译
需要额外说明的是，此工程是静态库的封装，我们最终产出物是DLL，运行方式是通过注入器LoadLibrary加载进去。
3.2 DllMain里如何安全地启动Hook线程
DllMain是DLL的入口点，很多人直接把Hook逻辑全部堆在里面，这是典型的错误写法。Windows加载器在DllMain阶段是持锁的，调用LoadLibrary、GetProcAddress这类API极容易造成死锁或崩溃。正确的做法是：在DLL_PROCESS_ATTACH里创建一个新线程，让线程函数去执行初始化逻辑。
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { if (ul_reason_for_call == DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hModule); HANDLE hThread = CreateThread(nullptr, 0, HookThread, hModule, 0, nullptr); if (hThread) { CloseHandle(hThread); } } return TRUE; }为什么必须CreateThread而不是直接掉初始化？因为我们要调用d3d11.dll里的函数，而d3d11.dll可能还没有被加载进来，需要调用LoadLibrary触发加载过程，这就会碰到加载器锁。DllMain里调用LoadLibrary极有可能卡死。
3.3 用Hooks直接拿设备指针：不动原业务代码的优雅方案
线程函数的第一件事是等待目标模块加载完毕，然后进入核心逻辑：Hook D3D11CreateDeviceAndSwapChain。
typedef HRESULT(WINAPI* D3D11CreateDeviceAndSwapChainType)( IDXGIAdapter* pAdapter, D3D_DRIVER_TYPE DriverType, HMODULE Software, UINT Flags, const D3D_FEATURE_LEVEL* pFeatureLevels, UINT FeatureLevels, UINT SDKVersion, const DXGI_SWAP_CHAIN_DESC* pSwapChainDesc, IDXGISwapChain** ppSwapChain, ID3D11Device** ppDevice, D3D_FEATURE_LEVEL* pFeatureLevel, ID3D11DeviceContext** ppImmediateContext); D3D11CreateDeviceAndSwapChainType RealD3D11CreateDeviceAndSwapChain = nullptr; HRESULT WINAPI HookD3D11CreateDeviceAndSwapChain( IDXGIAdapter* pAdapter, D3D_DRIVER_TYPE DriverType, HMODULE Software, UINT Flags, const D3D_FEATURE_LEVEL* pFeatureLevels, UINT FeatureLevels, UINT SDKVersion, const DXGI_SWAP_CHAIN_DESC* pSwapChainDesc, IDXGISwapChain** ppSwapChain, ID3D11Device** ppDevice, D3D_FEATURE_LEVEL* pFeatureLevel, ID3D11DeviceContext** ppImmediateContext) { HRESULT hr = RealD3D11CreateDeviceAndSwapChain( pAdapter, DriverType, Software, Flags, pFeatureLevels, FeatureLevels, SDKVersion, pSwapChainDesc, ppSwapChain, ppDevice, pFeatureLevel, ppImmediateContext); if (SUCCEEDED(hr) && ppSwapChain && *ppSwapChain && ppDevice && *ppDevice) { g_pSwapChain = *ppSwapChain; g_pDevice = *ppDevice; g_pContext = *ppImmediateContext; InitializeHook(); } return hr; }这里的核心思想是把真实函数指针保存为RealD3D11CreateDeviceAndSwapChain，我们的替身在调用完真实创建函数之后，把创建出来的设备、上下文、交换链指针缓存到全局变量，之后再做虚表替换。
这是整个Hook工程中最稳的一步，因为游戏不管什么时候调创建函数，我们的替身都能准确无误地截获到关键指针。注意这里必须保留原始函数的调用，否则游戏根本没设备可用。
3.4 用MinHook挂住Present：两行代码背后的学问
拿到交换链指针后，我们目标就是替换IDXGISwapChain::Present这个虚函数。
#include <MinHook.h> void* pPresent = nullptr; // 获取IDXGISwapChain的虚表 void** vTable = *reinterpret_cast<void***>(g_pSwapChain); pPresent = vTable[8]; // Present的虚表索引 if (MH_CreateHook(pPresent, &HookPresent, reinterpret_cast<void**>(&RealPresent)) != MH_OK) { return; } if (MH_EnableHook(pPresent) != MH_OK) { return; }这段代码看起来简单，但背后做了三件事：
第一，通过*reinterpret_cast<void***>(g_pSwapChain)拿到了对象内存头部指向的虚函数表，这是COM对象的标准内存布局，对象本身是一个指针，指针指向一坨函数指针数组。
第二，索引8对应Present，这个数字不是拍脑袋定的，我上面已经推导过，IUnknown 3个加上IDXGIObject 4个，再加上Present是第8个，除非微软未来改变IDXGISwapChain的布局，否则在Windows 10/11的DXGI里这个索引都是稳定的。
第三，用MH_CreateHook创建挂钩，再把钩子启用。MinHook内部会把原函数的前几条指令用绝对跳转指令覆盖，跳板代码负责保存现场、跳转到我们的Hook函数，并在必要时返回原函数继续执行。这个操作对X86和X64都有对应指令编码，我们不需要手写汇编。
3.5 Present替身的签名设计和绘制逻辑
现在是最兴奋的部分：写一个自己的Present替身函数。
using PresentType = HRESULT(STDMETHODCALLTYPE*)(IDXGISwapChain*, UINT, UINT); HRESULT STDMETHODCALLTYPE HookPresent(IDXGISwapChain* pSwapChain, UINT SyncInterval, UINT Flags) { // 我们自己的逻辑 if (bInitFrame) { RenderImGui(); } return RealPresent(pSwapChain, SyncInterval, Flags); }签名必须与原函数完全一致，这是用MinHook的前提。STDMETHODCALLTYPE在X86下会被展开成__stdcall，X64下无特殊修饰，MinHook会处理好跳板问题，我们只需要返回真实Present的返回值，保证交换链的调用链不断裂。
RenderImGui内部可以做的事情就多了：创建着色器、绘制三角形、叠加文字、截图帧缓冲、把帧数据转成纹理并推给视频编码器。最难的部分不在于画什么，而在于怎么在D3D11下正确复用游戏创建好的上下文进行Overlay绘制，这部分就涉及到D3D11状态保存和恢复，我在后面讲。
3.6 状态保存与恢复：很多人绕不过去的坎
如果你在Hook Present里直接调用ID3D11DeviceContext的绘制函数，往往会在下一帧发现游戏画面变花、某些物体消失或崩溃。原因很简单：你把游戏原本设置好的输入装配（Input Assembler）、光栅化状态、混合状态、深度模板状态全给改了，画完你的Overlay之后没有恢复原样。
一个成熟的Hook方案在绘制前应该做这么几件事：
- 调用
OMGetRenderTargets获取当前渲染目标视图和深度模板视图 - 调用
RSGetViewports保存当前视口 - 调用
IAGetPrimitiveTopology保存当前的图元拓扑 - 保存深度模板状态和混合状态
绘制完毕后，把所有这些状态按保存值恢复回去，再返回RealPresent。不保存现场的后果，轻则画面错乱，重则下一次DrawCall直接让驱动报错，触发设备移除。
当然，如果你只是用ImGui做UI叠加，ImGui的D3D11后端内部已经处理了很大一部分状态保存工作，它也要求在Begin/End之间保证独占上下文，所以我在框架里会把ImGui的绘制流程完整包裹在状态保存之间。
4. 实战验证与踩坑分享：从编译警告到黑屏崩溃的完整排错链路
4.1 32位和64位双边测试：为什么“支持X86_X64”不能只改一个编译选项
很多人在README里写着支持X86_X64，结果测试时发现32位版本好好的，64位版本一加载就崩。原因不外乎三个：MinHook库的版本选错、DLL位数和目标进程不匹配、函数指针类型没有按位数做条件编译。
我的工程里专门维护了下面这段：
#ifdef _WIN64 using HookFunc = void*; #else using HookFunc = void*; #endif本质上来讲，指针宽度不同，但C++层面用void*不会出错。真正会出错的是，如果Vector了MinHook的32位和64位版本，必须确保DLL版本和注入器版本一致，否则就是用64位的跳板区修补一个32位进程，Intel指令编码对不上，必崩。
其次是VTable索引问题。X86下DIrectX的COM虚表布局和X64下理论上含义一致，因为COM规范就是平台无关的，但我们在某些旧驱动或特定SDK版本下仍然遇到过索引漂移。稳妥做法是不硬编码索引8，而是在启动时动态寻找函数地址：利用设备的调试接口创建虚拟SwapChain，遍历虚表对比每个条目是否等于目标进程已经公开的Present地址。不过这个方法比较冷门，大多数情况索引8是可靠的。
4.2 最容易忽视的加载时序：目标进程还没创建设备怎么办
新手最常见的翻车现场是，DLL LoadLibrary注入成功，但目标进程此时还没调用D3D11CreateDeviceAndSwapChain，我们的Hook还没安装，游戏后面创建的设备就漏掉了。或者反过来，DLL注入太晚，游戏设备已经创建完成，我们还没装Hook，只能在未来创建的新设备上生效。
解决思路有两种，按需选用：
- 延迟初始化法：DLL加载后每隔一段时间检查一次是否有窗口句柄和交换链，有的话再安装Hook。
- 全局挂钩法：直接Hook ntdll或D3D11的导出函数，不管游戏什么时候创建设备，我们都在创建函数返回后截胡。
后者比较稳，我上面写的流程就是全局挂钩法，游戏加载d3d11.dll那一刻才会触发D3D11CreateDeviceAndSwapChain被调用，而我们的DLL已经先行Hook了导出表，所以万无一失。
但这里还有一个坑：如果在目标d3d11.dll还没被LoadLibrary之前，我们就调用GetProcAddress(GetModuleHandle(L"d3d11.dll"), "D3D11CreateDeviceAndSwapChain")，那返回的一定是空。所以线程函数里第一步要用LoadLibrary(L"d3d11.dll")把这个模块拉进进程，确保导出表可查。
所以正确的流程是：LoadLibrary(d3d11.dll) -> 获取真实函数地址 -> MH_CreateHook -> MH_EnableHook -> 后续游戏调用创建函数时自动进入替身。这一套流程走完，才能真正做到“支持X86_X64且不依赖注入时机”。
4.3 ImGui叠加显示：跑通第一帧彩色三角形时要注意的初始化顺序
我建议第一次跑通时，不要急着做复杂的ImGui界面，先在HookPresent里直接调用D3D11Draw绘制一个三角形，验证你的Present替身生效了。因为ImGui初始化涉及字体纹理上传、顶点缓冲创建、渲染状态设置等多层依赖，任何一个环节出错都可能黑屏，且很难定位。
绘制三角形的最小流程是：
- 创建ID3D11Buffer作为顶点缓冲，填入三个二维顶点
- 创建顶点着色器和像素着色器
- IASetPrimitiveTopology设置为三角形列表
- 调用Draw(3, 0)
如果你连这三点都跑不通，就要怀疑是不是PrevHook到Present但是绘制时的DeviceContext和游戏的不一致——有些游戏可能创建了多个DeviceContext，或者我们自己缓存了Copy。解决方案是不要缓存设备指针，每次在HookPresent里拿IDXGISwapChain::GetDevice获取设备，再GetImmediateContext得到上下文，确保拿到的是游戏当前正在用的那一个。
4.4 黑屏/闪退的几大元凶和快速定位手段
黑屏，这是最绝望的，但大部分原因其实很集中。
第一，DLL注入后目标进程崩在初始化流程。这类导致崩溃的直接原因往往是伪代码里访问了空指针，比如g_pSwapChain还没被赋值就调用了虚表操作。解决方案是在初始化前加条件判断。
第二，HookPresent里绘制时破坏了D3D11状态。解决方案见3.6的状态保存恢复。
第三，MinHook库和系统偏移不兼容。有些精简版MinHook在Win11 22H2上无法正常跳转，需要更新到最新版。判断方式是打开DebugView，看MH_CreateHook的返回值，MH_ERROR_UNEXPECTED模块被占用，那基本是库版本问题。
第四，我们自己的DLL可能使用了和多线程环境不兼容的全局初始化。这里有一个隐藏点，全局对象构造函数运行的时间点可能早于DllMain，如果构造函数里调用了需要d3d11.dll的函数，就会因为Loader Lock抛出奇怪错误。所以请把初始化逻辑全部放进HookThread线程中，全局变量只声明不初始化。
快速定位崩溃位置的办法，是用Visual Studio附加到进程，加载符号文件（输出地址），等崩溃时直接看call stack。大多数情况下，定位到HookPresent的调用栈顶端，就能看出是不是自己的绘制代码有问题。
5. 额外经验心得：生产级D3D11 Hook代码我还会加上什么
5.1 多实例和防重复注入
一个稳的Hook框架必须处理重复注入。DLL被多个模块反复注入时，可能创建多个Hook实例，导致函数被挂多层，最终性能损耗呈几何级增长。
我的方案是在DLL入口检查共享内存里的一个全局标记，比如CreateFileMapping创建一个命名互斥体，如果互斥体已经存在，说明DLL已经加载过一个实例，直接返回FALSE，不执行任何初始化，避免重复Hook。
5.2 和多线程渲染场景的兼容性
现代游戏通常有多个渲染线程。我们Hook的是Present，而Present调用往往只在一个线程上发生，但绘制Overlay时我们借用的是主线程的设备上下文，如果在其他线程同时调用D3D11命令，可能导致冲突。稳妥做法是给绘制函数加个互斥锁，或者用ID3D11DeviceContext::Map锁定资源，保证自己的绘制逻辑不会和游戏的其他线程产生争抢。
5.3 Hook链和卸载：怎么做到真正的无痕卸载
卸载是很多人忽略但生产环境必须考虑的事。MH_DisableHook可以恢复原始函数的前几条指令，但如果此时游戏还有其他模块依赖我们的函数，贸然卸载会导致后续调用进入空指针。
我的建议是：卸载时先关闭绘制标志位，线程等待下一个Present周期确认没有代码正在执行绘制，然后MH_DisableHook，最后FreeLibrary。真正常见的卸载时机是目标窗口关闭后的消息循环退出，而不是持续运行的进程中突然卸载。在共享DLL的框架中，放弃“完全无痕卸载”这种执念，通常只做“逻辑层优雅退出”，伤害会小得多。
5.4 帧数统计和性能开销控制
在Present挂Hook会带来一定的性能损耗，尤其是在每次绘制之前保存和恢复D3D11状态的操作，实测下来大概会吃掉2~5%的GPU时间。想降低开销，一个做法是只在帧时间内做必要的保存，另一个做法是直接把ImGui绘制逻辑放在Present替身里但让ImGui内部自己管理状态。
如果要统计帧数，注意不要使用QueryPerformanceCounter在不同线程中交叉计时，我一般的做法是在替身函数入口记录时间戳，出口再记一次，去掉最长的异常帧（如切换全屏时的大延时），取中位数，这样统计出的才是真正可用的帧率。
5.5 调试和日志：请对自己狠一点
最后一条可能听起来很基础，但确实能救你的命：在Hook代码里多写日志。不要用MessageBox，那会挂起窗口消息循环导致死锁，用OutputDebugString或者写文件日志都行。我在关键节点都会打日志，包括：
- DllMain何时被调用，目标模块是否加载
- 是否成功拿到D3D11CreateDeviceAndSwapChain地址
- MH_CreateHook返回值
- Present替身第一次被调用是否成功
- 绘制模块是否初始化成功
有了这些日志，遇到黑屏和崩溃时，你就能在DebugView里一眼定位问题出在哪个阶段，而不是瞎猜。
写在最后：这套代码我还能拿来做什么
D3D11 Hook的署名框架本身就是一类非常经典的“观察者模式”在图形层的落地，掌握了这段代码，你可扩展的空间非常大。
比如做画面性能统计工具，把Present的执行时间、GPU占用率、帧生成时间打点到日志或者叠加UI上。做自动截图工具，直接在Present替身里读回后台缓冲并保存为图片，比定期枚举桌面快得多。做自定义画质滤镜，VB技术里的调色和锐化，只需要在Draw之前通过PixelShader处理RT。
我个人在这套框架上还加过音画同步延迟的检测逻辑，利用Present时间戳和音频播放位置的时间差，能精准定位音视频不同步的偏移量，这个功能放到市面上任何一个播放器项目里都是加分项。
如果你打算在2025年还在做Windows图形开发，D3D11这个Hook框架真的是你工具箱里排得上号的利器。希望这篇源码级的拆解，能让你少踩一些我当年踩过的坑。
本文还有配套的精品资源，点击获取
