借助 windbg 调试 句柄泄漏

在做一个大工程的时候, 什么问题都有可能碰得上. 郁闷的是, 项目是多人合作的, 你无法确定问题出在谁的身上. 
最近就遇上一例.

描述:
引擎exe,运行10多分钟后, 自动退出. 我靠, 退的悄声无息的. 甚至连个windows抱歉的界面都不弹出来.

分析:
1: 关于程序悄声无息退出的问题
    一个程序出错, 一般都是windows很抱歉, 进程要关闭啥的, 问你要不要调试. 这次进程居然屁都不放一个就say88了.中间肯定有问题.
   进程出错, 一般windows都会生成响应的dump文件(内存转储),以供调试分析用. 而且如果指定了调试工具, 会提示调用相应的工具调试, 比如vs2005. 不同的电脑有不同的设置. 当时xEye是运行在小主机上的, 没有安装vs2005, 自然也没有提示调试. 
  但是, 我想, 一定有dump悄悄的生成了. 一般情况下, 这个在程序崩溃的时候, 生成dump的任务是drwtsn32.exe这个工具负责的. 为什么这个工具知道进程出问题了都不提示一下呢? 改改设置看看.
  运行=>drwtsn32=>选中视觉通知, 选中声音通知,选中故障转储文件.
  ok, 下次程序再崩掉的时候, drwtsn就会提示你了.

（2009-06-29日补充：多线程导致的问题，会让程序悄然退出！vs2005都拿其没则！崩溃线程任何有价值的信息都没有！后来发现，是线程间通信的数据结构不一致导致的！）

2:为什么程序会跑一段时间就退出?
  老聂同志发现xEye存在严重的句柄泄漏问题. 难道是此问题?
  通过任务管理器=>选择列=>可以显示进程的打开的句柄书, xEye的句柄以每秒100个的速度狂长.
  通过process explorer(微软的)工具, 查看xEye打开的句柄, 发现不断增加的是Event handle.
  但是代码里面没有CreateEvent()函数.
  问题处在哪里呢?

  请出windbg帮忙.
  固然不负重望. 通过一个视频教程里面演示用windbg检测句柄泄漏, 很快定位出是easyusb.dll的问题. 我靠. 这个原来是外来的动态库的问题.(此问题彤哥通过本方法,一个工程一个工程的替换, 也发现了是easyusb.dll的问题, 但是效率甚低)

2、windbg调试 
1）找到windbgs安装目录下的gflags.exe工具，该工具可用来打开windows自带的一些调试选项，具体gflags.exe的详细使用可以查看windbg帮助； 这里我们设置勾上application verifiwer，该工具主要可用来对程序做一些稳定性的检测，本次调试主要用于保存栈的相关信息。同时设置stack backtrace即栈的大小为10. 
2）运行windbg，打开第一步编译的程序，并使其跑起来；此时你查看任务管理器中的句柄信息，会发行相应进程句柄一直在增加。 
3）windbg用ctrl+break命令中断进程运行，用！htrace -enable命令开启句柄检测；htrace提供了进行句柄相关检测的命令，可查看windbg帮助。 同时用g命令让程序运行。 
4）再次中断进程，使用！htrace -snapshot命令，获得此时进程句柄的镜像。并再次让程序运行。 
5）第三次中断进程运行，我们再使用！htrace -diff命令获得当前句柄状态与第4步 snapshot镜像句柄的差异； 我们可以发现：新增很多打开的句柄，平常情况下这些打开的句柄有可能不是泄露，需要具体分析，但是本次示例程序太简单，所以刚好所有打开的句柄都属于泄露的。 
6）我们使用lsa 传递指定位置对应的代码，lsa handlew2!fun4+0x0000002e 到这里，我们就找到了泄露句柄的函数。
参考：
http://hi.baidu.com/firefly_only/blog/item/76f50e22945b9b5b9922ed6c.html

   ok. 修复之.

   现在句柄泄漏的问题搞定了, 但是进程还是跑一会就退出了!!!

   后来发现进程存在 栈溢出. 通过cdb(windbg的兄弟)很快也搞定了, 仍然是easyusb.dll问题. 如果仅查看异常时的调用堆栈, 会以为是classifying.dll的问题呢. 关于解决堆栈溢出的问题, 另有一片日志有记录.
　最后发现是底层驱动的问题．　ok, 这个话题扯远了, 非我辈能玩的起的了, 交给他们处理了.