当前位置：首页 > news >正文

MinHook 对.NET底层的 SendMessage 拦截真实案例反思

news 2025/6/12 17:39:08

一：背景

1. 讲故事

上一篇我们说到了 minhook 的一个简单使用，这一篇给大家分享一个 minhook 在 dump 分析中的实战，先看下面的线程栈。


0:044> ~~[138c]s
win32u!NtUserMessageCall+0x14:
00007ffc`5c891184 c3              ret
0:061> k# Child-SP          RetAddr               Call Site
00 0000008c`00ffec68 00007ffc`5f21bfbe     win32u!NtUserMessageCall+0x14
01 0000008c`00ffec70 00007ffc`5f21be38     user32!SendMessageWorker+0x11e
02 0000008c`00ffed10 00007ffc`124fd4af     user32!SendMessageW+0xf8
03 0000008c`00ffed70 00007ffc`125e943b     cogxImagingDevice!DllUnregisterServer+0x3029f
04 0000008c`00ffeda0 00007ffc`125e9685     cogxImagingDevice!DllUnregisterServer+0x11c22b
05 0000008c`00ffede0 00007ffc`600b50e7     cogxImagingDevice!DllUnregisterServer+0x11c475
06 0000008c`00ffee20 00007ffc`60093ccd     ntdll!LdrpCallInitRoutine+0x6f
07 0000008c`00ffee90 00007ffc`60092eef     ntdll!LdrpProcessDetachNode+0xf5
08 0000008c`00ffef60 00007ffc`600ae319     ntdll!LdrpUnloadNode+0x3f
09 0000008c`00ffefb0 00007ffc`600ae293     ntdll!LdrpDecrementModuleLoadCountEx+0x71
0a 0000008c`00ffefe0 00007ffc`5cd7c00e     ntdll!LdrUnloadDll+0x93
0b 0000008c`00fff010 00007ffc`5d47cf78     KERNELBASE!FreeLibrary+0x1e
0c 0000008c`00fff040 00007ffc`5d447aa3     combase!CClassCache::CDllPathEntry::CFinishObject::Finish+0x28 [onecore\com\combase\objact\dllcache.cxx @ 3420] 
0d 0000008c`00fff070 00007ffc`5d4471a9     combase!CClassCache::CFinishComposite::Finish+0x4b [onecore\com\combase\objact\dllcache.cxx @ 3530] 
0e 0000008c`00fff0a0 00007ffc`5d3f1499     combase!CClassCache::FreeUnused+0xdd [onecore\com\combase\objact\dllcache.cxx @ 6547] 
0f 0000008c`00fff650 00007ffc`5d3f13c7     combase!CoFreeUnusedLibrariesEx+0x89 [onecore\com\combase\objact\dllapi.cxx @ 117] 
10 (Inline Function) --------`--------     combase!CoFreeUnusedLibraries+0xa [onecore\com\combase\objact\dllapi.cxx @ 74] 
11 0000008c`00fff690 00007ffc`6008a019     combase!CDllHost::MTADllUnloadCallback+0x17 [onecore\com\combase\objact\dllhost.cxx @ 929] 
12 0000008c`00fff6c0 00007ffc`6008bec4     ntdll!TppTimerpExecuteCallback+0xa9
13 0000008c`00fff710 00007ffc`5f167e94     ntdll!TppWorkerThread+0x644
14 0000008c`00fffa00 00007ffc`600d7ad1     kernel32!BaseThreadInitThunk+0x14

这是一个 .NET某工控自动化控制系统(https://www.cnblogs.com/huangxincheng/p/16544462.html) 的卡死故障，经过一顿分析之后，找到了最后的卡死原因，即 cogxImagingDevice.dll 中有一个 DllMain 的卸载通知，熟悉 win32 的朋友都知道，代码经过 DllMain 的时候会持有一个 LdrpAcquireLoaderLock 进程加载锁，在持锁过程中它突然向一个窗体发送 SendMessageW 消息，可惜的是这个窗体没有给予响应，一直卡死在这里，这就导致 进程加载锁 迟迟得不到释放，引发系统性卡死。。。

如果有朋友还是比较懵的话，我画一张图给大家看看，黑色加粗就是问题的核心所在。

二：寻找解决方案

1. 现有困境

我可以通过 windbg 提取到 SendMessageW 方法的 窗口句柄 hWnd，通过这个 hWnd 找到创建它的 processID 和 ThreadID，但问题是这两个关键信息 是存放在当前机器的内核态中，言外之意就是用户态dump没有这两个信息，所以关键信息的缺失导致无法有效的排查出问题。

解决办法有两个:

抓内核态dump：由于 win32u 模块是闭源的，要想从内核态dump中找出还得不断的参考 reactos，费时费力。
SendMessageW跟踪：这个相对来说轻量级，也是本篇重点说的，即 minhook。

2. 如何跟踪 SendMessageW

我的想法是这样的，对 SendMessageW 进行拦截来获取 hWnd 参数，然后通过 hWnd 参数找到对应的 processid 和 threadid，然后再通过 processid 获取 processname，有了这三个信息就可以让对方无所遁形。

为了让大家眼见为实，我们做一个例子，新建一个 WindowsProject1 的Win32窗体，在网关函数 WndProc 中故意让程序卡死，参考代码如下：


LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{if (message == WM_CLOSE) {Sleep(1000 * 1000);}// todo....return 0;
}

接下来新建一个 ConsoleApplication 控制台程序，通过 SendMessage 给 WindowsProject1 打close消息，来演示无故卡死，完整的代码如下：


using System;
using System.Runtime.InteropServices;
using System.Text;namespace ConsoleApplication
{public static class Program{private const uint WM_CLOSE = 0x0010;public static void Main(){// 安装 HookHookManager.InstallHook();// 测试：发送 WM_CLOSE 消息（会触发 Hook）IntPtr hWnd = FindWindow(null, "WindowsProject1");if (hWnd != IntPtr.Zero){SendMessage(hWnd, WM_CLOSE, IntPtr.Zero, IntPtr.Zero);Console.WriteLine("Sent WM_CLOSE to target window.");}else{Console.WriteLine("Target window not found.");}Console.ReadKey();// 卸载 HookHookManager.UninstallHook();}[DllImport("user32.dll", CharSet = CharSet.Unicode)]private static extern IntPtr FindWindow(string lpClassName, string lpWindowName);[DllImport("user32.dll", CharSet = CharSet.Unicode)]private static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);}public static class HookManager{// SendMessageW 的原始函数签名[UnmanagedFunctionPointer(CallingConvention.StdCall, CharSet = CharSet.Unicode)]private delegate IntPtr SendMessageWDelegate(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);private static SendMessageWDelegate _originalSendMessageW;private static IntPtr _sendMessageWPtr = IntPtr.Zero;public static void InstallHook(){// 1. 获取 SendMessageW 的地址_sendMessageWPtr = MinHook.GetProcAddress(MinHook.GetModuleHandle("user32.dll"), "SendMessageW");if (_sendMessageWPtr == IntPtr.Zero){Console.WriteLine("Failed to find SendMessageW address.");return;}// 2. 初始化 MinHookvar status = MinHook.MH_Initialize();if (status != MinHook.MH_STATUS.MH_OK){Console.WriteLine($"MH_Initialize failed: {status}");return;}// 3. 创建 Hookvar detourPtr = Marshal.GetFunctionPointerForDelegate(new SendMessageWDelegate(HookedSendMessageW));status = MinHook.MH_CreateHook(_sendMessageWPtr, detourPtr, out var originalPtr);if (status != MinHook.MH_STATUS.MH_OK){Console.WriteLine($"MH_CreateHook failed: {status}");return;}_originalSendMessageW = Marshal.GetDelegateForFunctionPointer<SendMessageWDelegate>(originalPtr);// 4. 启用 Hookstatus = MinHook.MH_EnableHook(_sendMessageWPtr);if (status != MinHook.MH_STATUS.MH_OK){Console.WriteLine($"MH_EnableHook failed: {status}");return;}Console.WriteLine("SendMessageW hook installed successfully!");}public static void UninstallHook(){if (_sendMessageWPtr == IntPtr.Zero)return;// 1. 禁用 Hookvar status = MinHook.MH_DisableHook(_sendMessageWPtr);if (status != MinHook.MH_STATUS.MH_OK)Console.WriteLine($"MH_DisableHook failed: {status}");// 2. 卸载 MinHookstatus = MinHook.MH_Uninitialize();if (status != MinHook.MH_STATUS.MH_OK)Console.WriteLine($"MH_Uninitialize failed: {status}");_sendMessageWPtr = IntPtr.Zero;Console.WriteLine("Hook uninstalled.");}private static IntPtr HookedSendMessageW(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam){Console.WriteLine($"[HOOK] SendMessageW: hWnd=0x{hWnd.ToInt64():X}, Msg=0x{Msg:X}");// 获取窗口所属的线程和进程IDuint processId = 0;uint threadId = GetWindowThreadProcessId(hWnd, out processId);// 使用 System.Diagnostics.Process 获取进程信息string processName = "Unknown";try{var targetProcess = System.Diagnostics.Process.GetProcessById((int)processId);processName = targetProcess.ProcessName;Console.WriteLine($"Window belongs to - ThreadID: {threadId}, ProcessID: {processId}, ProcessName: {processName}");}catch (Exception ex){Console.WriteLine(ex.Message);}// 调用原始函数return _originalSendMessageW(hWnd, Msg, wParam, lParam);}// 需要的Win32 API声明[DllImport("user32.dll", SetLastError = true)]static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint processId);}public static class MinHook{public enum MH_STATUS{MH_OK = 0,MH_ERROR_ALREADY_INITIALIZED,MH_ERROR_NOT_INITIALIZED,// ... 其他状态码}[DllImport("MinHook.x86.dll", CallingConvention = CallingConvention.Cdecl)]public static extern MH_STATUS MH_Initialize();[DllImport("MinHook.x86.dll", CallingConvention = CallingConvention.Cdecl)]public static extern MH_STATUS MH_Uninitialize();[DllImport("MinHook.x86.dll", CallingConvention = CallingConvention.Cdecl)]public static extern MH_STATUS MH_CreateHook(IntPtr pTarget, IntPtr pDetour, out IntPtr ppOriginal);[DllImport("MinHook.x86.dll", CallingConvention = CallingConvention.Cdecl)]public static extern MH_STATUS MH_EnableHook(IntPtr pTarget);[DllImport("MinHook.x86.dll", CallingConvention = CallingConvention.Cdecl)]public static extern MH_STATUS MH_DisableHook(IntPtr pTarget);[DllImport("kernel32.dll", CharSet = CharSet.Unicode)]public static extern IntPtr GetModuleHandle(string lpModuleName);[DllImport("kernel32.dll", CharSet = CharSet.Ansi)]public static extern IntPtr GetProcAddress(IntPtr hModule, string lpProcName);}
}

最核心的代码是上面的 HookedSendMessageW，大家可以多品鉴品鉴，接下来依次运行 WindowsProject1 和 ConsoleApplication 程序，输出如下：

从输出看，是不是一下子就把排查范围缩小了很多，最起码我知道是一个叫 WindowsProject1 的进程坏了我的好事，后续就可以针对 WindowsProject1 深入探究为何方神物。。。

3. 还能更完美一点吗

虽然排查范围极大的缩小了，还但是有一点不完美，如果这个窗口是本进程创建的还好，如果不是本进程创建的，最好能抓到对方进程的dump那就真完美了。。。

接下来的问题是怎么抓对方进程的dump呢？为了确保通用性，我建议在本进程中调 procdump 自动捕获，参考代码如下：


namespace ConsoleApplication
{public class DumpGen{// 生成进程 Dump 文件public static void GenerateProcessDump(int processId, string dumpPath){try{// ProcDump 命令行参数：// -mm: 生成 MiniDump// -accepteula: 自动接受许可协议（避免首次运行时弹出提示）string procDumpPath = $@"{Environment.CurrentDirectory}\procdump.exe";string arguments = $"-accepteula -mm {processId} \"{dumpPath}\"";var startInfo = new ProcessStartInfo{FileName = procDumpPath,Arguments = arguments,UseShellExecute = false,CreateNoWindow = true,RedirectStandardOutput = true,RedirectStandardError = true};using (var proc = new Process { StartInfo = startInfo }){proc.Start();proc.WaitForExit();Console.WriteLine("Dump captured successfully");}}catch (Exception ex){Console.WriteLine($"Failed to launch ProcDump: {ex.Message}");}}}
}

然后修改下 HookedSendMessageW 方法，如果 _originalSendMessageW 超时，将会自动抓取dump，当然这里只是一个简单的演示，更复杂的逻辑大家可以根据自己的情况编写，比如用一个 字典 来存放 hWnd，然后根据超时时间自动的抓取进程的dump，参考代码如下：


private static IntPtr HookedSendMessageW(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam)
{Console.WriteLine($"[HOOK] SendMessageW: hWnd=0x{hWnd.ToInt64():X}, Msg=0x{Msg:X}");// 获取窗口所属的线程和进程IDuint processId = 0;uint threadId = GetWindowThreadProcessId(hWnd, out processId);// 使用 System.Diagnostics.Process 获取进程信息string processName = "Unknown";try{var targetProcess = System.Diagnostics.Process.GetProcessById((int)processId);processName = targetProcess.ProcessName;Console.WriteLine($"Window belongs to - ThreadID: {threadId}, ProcessID: {processId}, ProcessName: {processName}");//定时检测代码：如果超时自动抓取dumpTask.Run(() =>{Thread.Sleep(3000);if (Msg == 0x0010){string dumpPath = Path.Combine(Environment.CurrentDirectory, $"ProcessDump_{processName}_{DateTime.Now:yyyyMMddHHmmss}.dmp");DumpGen.GenerateProcessDump(targetProcess.Id, dumpPath);Console.WriteLine($"Launching ProcDump to generate dump: {dumpPath}");}});}catch (Exception ex){Console.WriteLine(ex.Message);}// 调用原始函数return _originalSendMessageW(hWnd, Msg, wParam, lParam);
}

一切都搞定之后，运行下程序，截图如下：

打开生成好的dump文件，找到目标线程，参考如下：


0:000> ~
.  0  Id: 4f34.338c Suspend: 0 Teb: 009c2000 Unfrozen1  Id: 4f34.6470 Suspend: 0 Teb: 009d2000 Unfrozen2  Id: 4f34.62a8 Suspend: 0 Teb: 009d6000 Unfrozen
0:000> ? 4f34 ; ? 338c; k
Evaluate expression: 20276 = 00004f34
Evaluate expression: 13196 = 0000338c# ChildEBP RetAddr      
00 00b3f910 77a23999     ntdll!NtDelayExecution+0xc
01 00b3f930 776a8760     ntdll!RtlDelayExecution+0xe9
02 00b3f998 776a86ff     KERNELBASE!SleepEx+0x50
03 00b3f9a8 00f81be3     KERNELBASE!Sleep+0xf
04 00b3fae8 76b36d13     WindowsProject1!WndProc+0x43 [D:\sources\woodpecker\ConsoleApplication\WindowsProject1\WindowsProject1.cpp @ 127] 
05 00b3fb14 76b2540d     user32!_InternalCallWinProc+0x2b
06 00b3fc18 76b24eb0     user32!UserCallWinProcCheckWow+0x49d
07 00b3fc7c 76b31709     user32!DispatchClientMessage+0x190
08 00b3fcb8 77a0bb66     user32!__fnDWORD+0x39
09 00b3fcf0 76b33ef0     ntdll!KiUserCallbackDispatcher+0x36
0a 00b3fd2c 00f81e9b     user32!GetMessageW+0x30
0b 00b3fe44 00f8273d     WindowsProject1!wWinMain+0xbb [D:\sources\woodpecker\ConsoleApplication\WindowsProject1\WindowsProject1.cpp @ 46] 
0c 00b3fe64 00f8258a     WindowsProject1!invoke_main+0x2d [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 123] 
0d 00b3fec0 00f8241d     WindowsProject1!__scrt_common_main_seh+0x15a [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0e 00b3fec8 00f827b8     WindowsProject1!__scrt_common_main+0xd [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331] 
0f 00b3fed0 76705d49     WindowsProject1!wWinMainCRTStartup+0x8 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_wwinmain.cpp @ 17] 
10 00b3fee0 779fcebb     kernel32!BaseThreadInitThunk+0x19
11 00b3ff38 779fce41     ntdll!__RtlUserThreadStart+0x2b
12 00b3ff48 00000000     ntdll!_RtlUserThreadStart+0x1b

从卦中看，原来卡死是因为主线程正在 KERNELBASE!Sleep，无语了，到此为止，这次卡死事故真相大白于天下。