[原]windbg调试系列——崩溃在ComFriendlyWaitMtaThreadProc

dotNET跨平台

于 2019-12-02 07:10:00 发布

阅读量183

点赞数

前言

这是几年前在项目中遇到的一个崩溃问题，崩溃在了ComFriendlyWaitMtaThreadProc()里。没有源码，耗费了我很大精力，最终通过反汇编并结合原代码才最终搞清楚了事情的来龙去脉。本文的分析是基于真实项目进行的，中间略去了很多反汇编的分析工作。文末有我整理的测试代码，大家可以实际体验一把TerminateThread()的杀伤力。

背景介绍

大概情况是这样的：程序启动的时候，会通过LoadLibrary()加载插件模块。其中的UIA模块会开启一个工作线程，工作线程会安装UIA相关的钩子来监听UIA事件，程序在退出的时候会调用每个插件模块的导出函数做清理工作，然后调用FreeLibrary()释放这个插件模块。UIA模块的清理函数会通知工作线程退出，工作线程收到退出命令后会卸载相关钩子。清理函数会等待工作线程一段时间，等待超时就通过TerminateThread()强制杀死工作线程。程序退出时偶尔会崩溃在ComFriendlyWaitMtaThreadProc()中。背景介绍完毕，下面开始分析dump文件。

问题分析

使用windbg载入dump文件，输入.ecxr

.ecxr

从输出结果可以看出是访问到无效的地址0x07acf914了，使用命令!address 07acf914查看该地址的信息：

!address 07acf914

从输出结果可以看出该地址确实是不可访问的。我们需要看看0x07acf914 是从哪里来的，该值来自edi+4指向的地址所存储的值，那么edi的值是哪里来的呢？让我们看看前几条汇编指令是什么，输入ub 7303f614 L10

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()的调用约定来判断。

输入k查看调用栈：

从调用栈可知，ComFriendlyWaitMtaThreadProc()是在新线程中执行的，通过查看CreateThread()的原型我们可以知道 ComFriendlyWaitMtaThreadProc() 原型应该满足typedef DWORD (__stdcall LPTHREAD_START_ROUTINE)(LPVOID lpThreadParameter); 。

综上可知，ebp+8确实指向了第一个参数，这个参数指向了一个非法的地址!

我猜测有如下两种可能：

调用函数传递了一个合法地址，由于某种原因这个地址无效了。（最后证明，我们的代码里传递了一个栈上的局部变量，但是调用线程挂掉了，栈对应的内存无效了！）
代码中存在bug，传递参数的时候就传的有问题！（可能性太低了，对自己的代码比较有信心????）

追本溯源

单纯从dump看不出更多的信息了！于是我决定在 ComFriendlyWaitMtaThreadProc()中设置断点，看看是否能找到是谁创建了这个线程! 执行如下命令：

bu uiautomationcore!ComFriendlyWaitMtaThreadProcg

断下来后，使用~*k查看所有线程的调用栈，经过排查，11号线程和18号线程最值得怀疑。

thread-11

thread-18

18号线程是出问题的线程。

11号线程包含我们自己的代码，而且ComFriendlyWaitForSingleObject()跟ComFriendlyWaitMtaThreadProc()相似度不要太高。

大胆猜测内部逻辑应该是：函数AddWinEvent()内部会创建一个工作线程，uiautomationcore!ComFriendlyWaitMtaThreadProc()是新线程的入口函数，创建完线程后通过调用ComFriendlyWaitForSingleObject()等待一个内核对象（通过反汇编确认该对象为Event）来等待工作线程结束。理所当然的，uiautomationcore!ComFriendlyWaitMtaThreadProc()结束后应该会激活这个内核对象。

经过一系列的小（艰）心（苦）谨（卓）慎（绝）的反汇编，检查代码，确认逻辑，最终得到如下结论：

当主程序退出时，主线程做清理工作，会等待11号线程一段时间，如果等待超时就会调用TerminateThread()将其强行杀死（正是这个TerminateThread()的调用导致了崩溃）! 而18号线程会用到11号线程传过来的线程参数（11号线程的一个局部变量），如果11号线程被意外杀死了，那么11号线程的局部变量对应的地址就无效了，对这块内存的操作就是未定义的！至此真相大白！（中间还有很多相关细节太琐碎了，没有一一列出，这里直接写出了结论。）

解决

知道原因了，解决起来就很简单了。去掉对TerminateThread()的调用，由操作系统来清理未结束的线程即可。由于主程序会调用FreeLibrary()释放插件模块，所以主程序还需要特殊处理下，在退出的时候不调用FreeLibrary()释放UIA模块。

为了让大家更好的理解问题的本质，更直观的感受下TerminateThread()的杀伤力，我特意编写了如下测试代码来模拟我在项目里遇到的问题。

测试代码

#include "stdafx.h"#include "windows.h"#include "process.h"
unsigned __stdcall SubWorkProc(void* param){  int* data = (int*)param;  while (1)  {    *data = 1;    Sleep(1000);  }
  return 0;}
unsigned __stdcall WorkProc(void* param){  int data = 0;  _beginthreadex(NULL, 0, &SubWorkProc, &data, 0, NULL);  while (1)  {    Sleep(1000);  }
  return 0;}
int _tmain(int argc, _TCHAR* argv[]){  auto hThread = (HANDLE)_beginthreadex(NULL, 0, &WorkProc, NULL, 0, NULL);  Sleep(1000);  TerminateThread(hThread, 0xdead);  Sleep(INFINITE);  return 0;}