某一天，点击VS的单个测试用例时，发现卡死了，VS提示没有响应，以下是测试工程的结构：

提示如下：

当时简单用windbg看了下，没有看出原因。因为当时可以使用命令行选项来跑单个测试用例，所以这个问题就搁置了。

之后重装了操作系统，发现没有这个卡死问题了。一段时间后，结果又出现了这个卡死。看来还是得把这个问题解决，在VS的UI测试单元测试用例还是挺实用的。

盲猜诱因

之前有一次停电，然后电脑没关，导致了电脑突然关机，有些进程没有及时保存各自的数据。于是怀疑是VS的缓存一致性被破坏了。

参考microsoft社区的回答，清空了以下三部分：

• Component Cache

  Close Visual Studio (ensure devenv.exe is not present in the Task Manager) and delete the C:\Users\xxxx AppData\Local\Microsoft\VisualStudio\your version xxx\ComponentModelCache directory

• Temp folder

  Delete the C:\Users\xxxx \AppData\Local\Temp directory

• Roslyn folder

  C:\Users\xxxx\AppData\Local\Microsoft\VisualStudio\Roslyn

重启VS，结果依旧卡死。清除缓存不行，看来只能上windbg了。

初步分析

VS是32位的，一般启动不会有管理员权限，所以用windbg直接附加就可以分析了。

windbg安装：windbg属于WDK的一部分，安装请参考这篇官方文档。

因为是界面卡死，然后界面对应的线程是主线程，主线程在windbg里是0号线程，所以切过去，看下栈：

栈帧0-2的前两个参数是等待的句柄数和句柄数组：

可以看到这个句柄表示一个事件，且是non-signaled状态。值得注意的是这个句柄被打开了两次(HandleCount)，可猜测有一个线程获取了这个事件，而主线程在等待这个事件，结果那个线程有没有将这个事件值为signaled状态，导致死锁。

栈帧继续往下看，观察3-6，关于combase模块，从模块的函数名可看出该模块负责等待；然后栈帧3是vslog模块用inlinehook的方式劫持等待函数，用于记录等待事件，无响应的窗口弹出应该就是通过这种方式实现的，即记录等待的时间，如果超时就提示。

再观察栈帧8-16，可看到进入等待的一个流程。从17开始，就看不到模块名了，这是因为.net程序的托管代码需要通过clr模块的jit化，编译成机器码（汇编代码）才能执行，所以这一片内存是clr专门为动态jit化的代码分配的内存，所以看不到模块信息。

栈帧再往后就是一些.net模块的栈，其中可看到一些C#的函数，不过都属于框架的东西、多线程异步调用，没有太多参考内容。

观察其他线程的信息，没找到相关有用的信息，那现在的线索就只有主线程的等待流程了，即栈帧8-16了。

等待流程分析

为方便阅读，这里把栈帧8-16单独提出来

为什么会一直等待一个事件句柄呢，这需要细看这个句柄是哪里来的。仔细观察栈帧的参数部分，可看到句柄数组最后出现在栈帧10，也就是说CLREventBase::WaitEx提供了等待事件的句柄给Thread::DoAppropriateWait函数。那打开IDA，开始解析clr模块，观察CLREventBase::WaitEx函数：

可看到v7变量是this指针，this变量是CLREventBase实例，而this变量就是等待的数组地址，由此可知CLREventBase是一个没有虚表的类，第一个成员就是等待事件的句柄。

接下来要看CLREventBase实例是在哪生成的，观察栈，在IDA寻找，如下：

可看到CLREventBase实例其实是AwareLock类的一个成员，从Wait的调用往上，可看到AwareLock::AllocLockSemEvent函数，该函数会调用CLREventBase::CreateMonitorEvent，然后CreateMonitorEvent方法会调用CreateEventW(0, 0, 0, 0)来创建事件，这个事件就是0-2栈帧等待的事件句柄。观察到AllocLockSemEvent函数的调用有一个条件：

如果this+6*4 地址处的成员变量的第4位不为0，则认为不需要创建事件句柄，这里可理解为第4位不为0，则事件句柄就是存在的，和单例模式的实例创建类似，如果没有才创建。继续往上回溯，看AwareLock的实例是怎么来的：

这是16号栈帧，最后一个有用的栈帧，从代码可看出AwareLock的实例是从ObjHeader::GetSyncBlock来的，google一下该函数，发现这个函数是获取对象的同步块。那这个对象是什么时候，从哪创建的呢？

分析到这里，线索断了。

.NET程序调试

其实，我们之前是在调试非托管代码，而.NET程序存在文件中的元数据包含的是托管代码，托管代码通过jit化，转成机器码并执行。

只分析非托管代码，能获取的信息是有限的，因此最后还是需要分析托管代码，.NET框架提供了一个sos扩展，该扩展可方便windbg观察托管代码的数据，比如栈、函数的变量和参数等。

因为对sos扩展的使用不熟，所以之前尝试了非托管代码的分析，目前看来走不通了，那就从整体.NET程序的流程来分析。

加载sos.dll

为使用sos模块，需要显式在windbg中加载sos模块，加载的方法有两种：

• .load <sos_dll_path>

• .loadby sos <some_module_path>

  这里的some_module_path是和sos在同一个目录的模块，且已经被加载到进程里了。

关于sos模块的基本使用方法可参考微软的这篇官方文档。

从托管代码的角度观察栈

从以上命令可看到，有时即使执行了.load和.loadby命令，帮助文档还是打不开，但使用了sos的其中一个命令后，就可以打开帮助文档了。

关于sos有哪些命令，可在微软的官方了解，也可以用!sos.help来了解，如果要了解某一条具体的命令，可以输!help sos_command：

了解了sos的基本资料后，我们观察下完整的主线程的栈：

首先GCFrame是保护对象引用的，其实不是方法调用，如下：

往下看，可以看到Microsoft.CodeAnalysis.Options.GlobalOptionService.RefreshOption是调用等待的函数，这个函数是C#语言的函数，我们可以找到该函数所处模块，然后用dnSpy反编译代码查看对应的代码。为找到该函数对应的模块，首先使用!CLTStack -a命令打印所有栈帧：

因为某些原因，我重启了VS，以下偏移会不太一样，不过不影响分析流程的理解。

Microsoft.CodeAnalysis.Options.GlobalOptionService的类实例是0x3a4d75b4，点击这个地址，会执行命令!DumpObj /d 3a4d75b4，该命令结果如下：

其中有一个File字段，这个字段对应的RefreshOption方法的所在模块。

题外话，DumpObj的结果还有一个MethodTable字段，点击地址，会执行!DumpMT /d 17196770命令，输出这个类的方法统计信息。由于这样无法打印该类的所有方法，所以我们通过执行!help DumpMT命令，可以查看其具体用法，如下：

所以，最终执行!DumpMT /d -MD 17196770命令可查看该类的所有方法，如下：

紧接正文，找到模块后，用dnSpy打开，查看如下代码：

根据我们在非托管代码的分析，当时的等待事件句柄应该就是这个this._gate对象里的事件句柄了。从代码中可了解到，应该是其他线程锁住了_gate这个对象，导致主线程一直等待，然后锁住_gate的线程又因为什么原因，一直在等待，所以导致了死锁。那么锁住_gate的线程是谁呢？这时就需要打印所有线程的栈了。

观察所有线程的栈

运行命令~*e !CLRStack，打印所有线程的栈，其中发现一个与GlobalOptionService类有关的线程，其栈如下：

注：在'~*'后面要跟一个'e'，这样才能对所有线程执行扩展命令。

该线程也在等待，其中GlobalOptionService的最后一个调用是GlobalOptionService.g__GetOptionPersistersSlow|16_0，观察源代码:

因为该函数是最后一个函数，即workspaceThreadingService不为null。从栈来看，调用workspaceThreadingService.Run方法后，就调用Microsoft.VisualStudio.Threading.JoinableTask.CompleteOnCurrentThread()，做同步等待，即等待异步的g__GetOptionPersistersAsync|16_1函数执行完成。

g__GetOptionPersistersAsync|16_1方法如下：

<<GetOptionPersisters>g__GetOptionPersistersAsync|16_1>d 是编译器生成的类，应该属于lambda、闭包那一类。该类实现了IAsyncStateMachine接口，该接口有一个MoveNext方法，在该类的实现如下：

调用SelectAsArrayAsync函数，该函数接收一个参数<GetOptionPersisters>b__16_3，这个参数是一个函数，该函数实现如下：

GetOrCreatePersisterAsync函数是IOptionPersisterProvider接口的一个函数，该函数会在另一个线程执行。再往回看主线程的栈

最底下是异步调用，然后异步调用会调用LanguageSettingsPersisterProvider类的相关函数，执行!CLRStack -a命令，找到这个类对应的模块名为

Microsoft.VisualStudio.LanguageServices.dll，用dnSpy打开，定位到该类，发现恰好有GetOrCreatePersisterAsync函数：

也就是说IOptionPersisterProvider接口的实现类是LanguageSettingsPersisterProvider，该函数负责执行状态机类<GetOrCreatePersisterAsync>d__5，也就是主线程栈上的LanguageSettingsPersisterProvider+d__5类的MoveNext函数。MoveNext函数会新建一个LanguageSettingsPersister实例：

该构造函数会初始化一个map，描述语言配置，比如C#、F#，如果_textManager.GetUserPreferences4能获取到对应语言的配置，那么就调用RefreshLanguageSettings，进一步调用RefreshOption更新选项配置：

这与主线程的栈是一致的。到这里梳理一下流程：

红圈中两个线程相互等待，导致死锁。

VS卡死的原因

根据调试分析，发现如果有对应的语言配置，就会去更新选项配置。回想起不久前，我安装了C#的开发环境，可能是因为这样，导致VS能找到C#的语言配置，所以走入了新流程，即更新选项配置，但这时由于另一个线程锁住了_gate，所以这就导致主线程的等待。

解决问题

既然大概有眉目了，那第一种方法就是卸载C#的开发环境。不过这不是长久之计，还是需要更优雅的方法。google之后，我发现roslyn开源库里正好提到了这个问题，有一个open的issue，并且开发者在高版本还修复了这个问题，merge是这个，关键代码如下：

这里persister类实例的构建放在了gate对象锁的外面，这样就不会导致主线程无限等待了。

也就是说更新对应Microsoft.CodeAnalysis.workspaces.dll的版本就行了，我尝试更新了.NET的运行时，似乎都没更新这个dll，最后我下载了VS的扩展开发组件，该组件包含了roslyn的对应dll，替换dll后问题解决。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！