在无法获取DebugDiag来分析崩溃转储文件后，建议我尝试使用WinDbg。
崩溃转储文件是在Windows Server 2016盒子上创建的，在IIS-10上运行我的ASP.Net 4.5.2 web应用程序。我的ASP.Net web应用程序包含几个第三方组件，以及它们各自的DLL。
我已经将崩溃转储文件复制到我的Windows 10开发机器上，并在本地运行WinDbg，而不是在服务器上。
问题是…当我在WinDbg中对任何崩溃转储文件运行!analyze -v时，它在"下载文件xxx.DLL"(xxx.DLL只是其中一个第三方组件DLL的名称)时有效地挂起，并最终在一段时间后自行取消。
我正在同一台机器上运行WinDbg，我在第一时间建立了网站那么有没有办法告诉WinDbg它可以在本地机器上的特定位置找到DLL
我显然没有任何第三方组件的.pdb文件，所以我不介意它为那些DLL加载符号。。。但要么我以某种方式告诉它忽略那些特定的DLL，要么我告诉它如何在本地找到它们。
有人能给我指正确的方向吗？
您不必使用分析转储文件！分析。如果你需要加载dll，那么.load D:。。。。足够了。
分析转储文件。请运行.loadb-sos-clr以加载调试模块。如果崩溃服务器和您的计算机运行不同版本的.net框架。然后您需要手动加载sos.dll。
当您需要在IIS中调试.net应用程序时！建议扩展mex。https://www.microsoft.com/en-us/download/details.aspx?id=53304
您可以通过.loadc:.....mex.dll加载mex.dll
!mex.aspxpages可以显示进程内的所有请求及其进程
!mex.mthreads显示所有线程的状态
!mex.clrstack2将显示特定线程中的所有异常和管理调用堆栈。
1.您可以使用~* k加载所有线程中的完整调用堆栈和!mex.mthreads检查状态。然后你可能会在特定的线程中找到类似KERNELBASE!RaiseException的东西
2.然后像12~一样通过threadid~转到该线程
3.运行!mex.clrstack2，会显示崩溃异常
基本上，不，您无法加快为没有符号的DLL加载符号的过程。IMHO，加速符号处理的唯一方法是禁用HTTP服务器，这样只在本地磁盘上搜索符号。
另请参阅：如果您不经常这样做，如何在WinDbg中设置符号。
为这些文件获取HTTP 404应该不会花很长时间。然而，它会尝试各种文件结尾和指针等。有时Microsoft服务器速度很慢。当然，拥有大量的第三方DLL也可以作为总结。这可能很令人反感。
我首先要说的是，我不能100%理解我必须做的一切，但以下是我发现应用程序中stackerflow问题的步骤。。。
大部分信息来自这个博客。
-
在服务器上，我添加了以下注册表设置来创建崩溃转储文件。。。
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps] [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumpsw3wp.exe] "DumpCount"=dword:00000005 "DumpFolder"=hex(2):43,00,3a,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75, 00,6d,00,70,00,73,00,5c,00,00,00
(DumpCount是开始覆盖旧文件之前要存储的文件数-DumpFolder是要保存文件的位置，是REG_EXPAND_SZ，在我的情况下代表C:CrashDumps)
- 等待崩溃发生
- 将崩溃文件复制到我本地机器上名为
C:WinDbgCrashDumps的目录中 - 创建另一个名为
C:WinDbgSymbols的目录，我将。。。clr.dll(来自服务器，取自C:WindowsMicrosoft.NETFramework64v4.0.30319)sos.dll(来自服务器，取自C:WindowsMicrosoft.NETFramework64v4.0.30319)- 本地开发环境中的所有
.dll和.pdb文件，包括第三方组件.dll文件
- 通过Windows应用商店在我的Windows 10开发机器上安装
WinDbg - 通过Run命令运行
windbgx -y c:windbgsymbols(出于某种原因，我的机器上是windbgx，但可能是因为它是通过Store而不是手动下载) - 在文件菜单
Open dump file中，选择C:WinDbgCrashDumps中的一个转储文件 - 运行以下命令。。。
.symfix.reload.load c:windbgsymbolssos.dll(见下文注释1)!clrstack(见下文注释2)
虽然这并没有给我提供我所期望的所有信息，但它确实表明，我的一个第三方组件对stackoverflow异常负有100%的责任。
注意1-我读到很多地方都说应该使用.loadby sos clr，但这只是给了我The call to LoadLibrary(C:ProgramDataDbgsymclr.dll5E7D1F3B9eb000sos.dll) failed，我不知道如何修复它…所以我使用了.load c:windbgsymbolssos.dll。
注意2-!clrstack命令之所以有效，是因为WinDbg似乎预先选择了出现异常的线程。另一个选项是使用~*e !clrstack，它将显示所有线程的调用堆栈。