原]windbg调试系列——崩溃在ComFriendlyWaitMtaThreadProc-工商资讯网

　　这是几年前正在项目中遭遇的一个溃散题目，溃散正在了ComFriendlyWaitMtaThreadProc里。没有源码，耗损了我很大元气心灵，最终通过反汇编并连接原代码才最终搞大白了事宜的前因后果。本文的判辨是基于切实项目举办的，中心略去了许多反汇编的判辨做事。文末有我整顿的测试代码，大师能够实践体验一把TerminateThread的杀伤力。

　　大致情景是如此的：轨范启动的功夫，会通过LoadLibrary加载插件模块。个中的UIA模块会开启一个做事线程，做事线程会装置UIA闭连的钩子来监听UIA事务，轨范正在退出的功夫会移用每个插件模块的导出函数做清算做事，然后移用FreeLibrary开释这个插件模块。UIA模块的清算函数会闭照做事线程退出，做事线程收到退出夂箢后会卸载闭连钩子。清算函数会守候做事线程一段时代，守候超时就通过TerminateThread强造杀死做事线程。轨范退出时有时会溃散正在ComFriendlyWaitMtaThreadProc中。布景先容完毕，下面起初判辨dump文献。

　　从输出结果能够看出是探访到无效的地方0x07acf914了，利用夂箢!address 07acf914查看该地方的讯息：

　　从输出结果能够看出该地方确实是弗成探访的。咱们需求看看0x07acf914 是从哪里来的，该值来自edi+4指向的地方所存储的值，那么edi的值是哪里来的呢？让咱们看看前几条汇编指令是什么，输入ub 7303f614 L10

　　证明：7303f614这个地方是我通过7303f611+3算来的（3是地方7303f611对应的指令长度），如此就能够正在输出结果中看到导致溃散的这条指令啦。当然这里输入ub 7303f611也不要紧（咱们闭注的是edi的值是哪里来的），只能是咱们看不到7303f611对应的指令了。

　　咱们浮现edi的值来自ebp+8对应的地方实质。研讨过反汇编的幼伙伴儿该当对ebp+n比力敏锐，有木有？正在windows下，32位历程中，ebp+8指向了移用商定为__stdcall的函数的第一个参数。这里的ebp+8是否指向第一个参数，咱们需求通过ComFriendlyWaitMtaThreadProc的移用商定来剖断。