【问题标题】:How to debug in-process hosted ASP.Net Core apps with WinDBG and SOS?如何使用 WinDBG 和 SOS 调试进程内托管的 ASP.Net Core 应用程序?
【发布时间】:2019-01-10 10:38:10
【问题描述】:

我有一个面向 .Net Core 2.2 的 ASP.Net Core 2.2 应用程序。我使用新的in-process hosting model 在 Azure 应用服务上托管它。 然后我通过应用服务诊断工具创建内存转储。使用 Visual Studio 打开它,我看到两个 CLR 版本:4.7.3190.0; 4.6.27110.4。我可以看出 4.7.3190.0 用于 .Net Framework,而 4.6.27110.4 用于 .Net Core。 如果我在 WinDBG 中打开转储,它会继续加载 4.7.3190.0 的 mscordacwks DLL。我无法让它加载 4.6.27110.4 的 mscordaccore DLL。因此,一个简单的 SOS 命令(例如 !Threads)会导致错误 Failed to request ThreadStore

如何使用 WinDBG 和 SOS 调试我的托管代码(.Net Core 部分)?

您可以获取示例内存转储here

更新

感谢Thomas Weller 的大力帮助!这种情况的解决方案是运行.cordll -u -I coreclr -l -lp "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0\"。我必须在一个命令中卸载 (-u) CLR DAC 并加载 (-l) Core CLR DAC。

成功的命令和日志是here

【问题讨论】:

  • 您应该为您的应用服务禁用 ASP.NET 4.x,以消除 .NET Framework 噪音。 .NET Core 调试应遵循bret.codes/net-core-and-windbg 等初始步骤
  • @LexLi:你能教我如何为我的应用服务禁用 ASP.NET 4.x 吗?我只能在门户中选择 3.5 和 4.7,但无法禁用它。

标签: iis asp.net-core windbg azure-web-app-service


【解决方案1】:

一般来说,我会说,看看.cordll 命令。具体来说,

0:000> .cordll -u
CLR DLL status: No load attempts

卸载 CLR DAC 和

0:000> .cordll -I coreclr -l -lp "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0\"
CLR DLL status: Loaded DLL f:\debug\symbols\mscordaccore_AMD64_AMD64_4.6.27110.04.dll\5BE756335c6000\mscordaccore_AMD64_AMD64_4.6.27110.04.dll

从特定路径加载 .NET Core DAC。


在您的故障转储中,有 2 个 CLR 版本:

0:000> lm m *clr
start             end                 module name
00007ffc`ac990000 00007ffc`acf56000   coreclr    (deferred)             
00007ffc`c2130000 00007ffc`c2b1d000   clr        (deferred)

详情是

0:000> lmvm clr
[...]
    File version:     4.7.3190.0
0:000> lmvm coreclr
[...]
    File version:     4.6.27110.4

正如 Visual Studio 所示。

如果您执行通常的.loadby sos clr,它将从clr 所在的位置加载4.7 版本的SOS。不幸的是,.loadby sos coreclr 不会以同样的方式工作,因为 .NET Core 的调试支持与 .NET 不同。

0:000> .loadby sos coreclr
The call to LoadLibrary(D:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0\sos) failed
Win32 error 0n126 "The specified module could not be found."

如果您安装了匹配的 .NET Core 包,则在 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0\ 之类的路径中有一些 SOS 版本。然后,您可以从该路径显式加载扩展:

0:000> .load C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0\sos.dll

确保你卸载了 CLR 的 SOS:

0:000> .unload C:\...\sos.dll

并与.chain 确认仅加载了一个 SOS。

【讨论】:

  • 谢谢。但是你能分享一下.cordll -u -l -lp的模式细节吗?我跑了.cordll -u -l -lp "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0",得到了CLR DLL status: Loaded DLL C:\ProgramData\Dbg\sym\mscordacwks_AMD64_AMD64_4.7.3190.00.dll\5B693B489ed000\mscordacwks_AMD64_AMD64_4.7.3190.00.dll。而!Threads 仍然返回Failed to request ThreadStore
  • 谢谢,但还是不行。这是控制台日志。 0:000> .unloadUnloading MexOMStub extension DLL0:000> .cordll -u -l -lp "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0"CLR DLL status: Loaded DLL C:\ProgramData\Dbg\sym\mscordacwks_AMD64_AMD64_4.7.3190.00.dll\5B693B489ed000\mscordacwks_AMD64_AMD64_4.7.3190.00.dll
  • 好像新的WinDbg(引擎版本10.0.18309.1000)一直在加载mscordacwks_AMD64_AMD64_4.7.3190.00.dll
  • 我已经把.chainhere的输出放到了。
  • 即使在我显式运行.unload MexOMStub .unload DbgEngCoreDMExt.unload C:\ProgramData\Dbg\sym\SOS_AMD64_AMD64_4.7.3190.00.dll\5B693B489ed000\SOS_AMD64_AMD64_4.7.3190.00.dll.load C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.0\sos.dll.chain 后返回this.cordll 仍然返回CLR DLL status: Loaded DLL C:\ProgramData\Dbg\sym\mscordacwks_AMD64_AMD64_4.7.3190.00.dll\5B693B489ed000\mscordacwks_AMD64_AMD64_4.7.3190.00.dll
猜你喜欢
  • 2019-08-08
  • 2017-01-13
  • 1970-01-01
  • 1970-01-01
  • 2017-12-16
  • 2019-01-20
  • 2013-08-03
  • 2012-09-04
  • 2020-11-22
相关资源
最近更新 更多