如何洞察 .NET 程序非托管句柄泄露

很多朋友可能会有疑问，C# 是一门托管语言，怎么可能会有非托管句柄泄露呢？ 其实一旦 C# 程序与 C++ 语言交互之后，往往就会被后者拖入非托管泥潭，让我们这些调试者被迫探究 非托管领域问题。,为了方便讲述，我们上一个 Event 泄露的案例，使用 C# 调用 C++ ，然后让 C++ 产生 bug 导致句柄泄露。,先看一下 C++ 代码,然后导出一个 CSharpCreateEvent 方法给 C# 使用。,程序跑起来后，在任务管理器中会发现这个句柄在不断的上涨，截图如下：,图片,如果你的生产环境可以用 WinDbg 附加进程，那用它就可以轻松解决，可以借助 !handle 命令看一下泄露的句柄类型。,从统计信息看，当前 Event 高达 1337 个，看样子程序存在 Event 泄露，接下来我们就要洞察到底是谁分配的 Event，如果能找到分配 Event 的线程栈，那这个问题就会迎刃而解，对吧，有 WinDbg 在，方圆3公里的bug都要移民，追踪调用栈可以使用 WinDbg 提供的 !htrace 命令。,它的原理很简单，一句话表示就是：挖出现在时间点和快照之间那些没有被 free 处理的 handle 调用栈，结果一清二楚，参考代码如下：,从卦中短暂的时间内快照之间有 170 个句柄没有被释放，而且从调用栈看是 Example_20_1_5!CSharpCreateEvent 方法所致，但这里有一个问题，虽然有非托管栈，但没有看到任何托管部分，那怎么办呢？,其实这个问题很简单，既然都 WinDbg 附加了，干脆用 bp 下断点，后续泄露之时必然会被命中，然后通过 !clrstack 或者 k 观察线程栈即可，有了思路就开干。,从卦中看，一切都非常明白，这里再补充一点，如果想中途再产生 快照，可以用 -snapshot 命令创建一个初始点，参考如下：,handle 泄露也是一个比较难搞的问题，难点在于生产环境可能不让你用 WinDbg 这种侵入方式，但问题还得要解决，必须创造条件上，当前除了 WinDbg 还没有找到其他方式，有机会再研究下吧。