Logo

菜单

Administrator
发布于 2024-12-20 / 1 阅读
0

调试没有显示错误行号

title: 调试没有显示错误行号
tags:

  • WINDBG
  • lines
  • pdb
  • dump
    cover: 'https://tuapi.eees.cc/api.php?category=dongman&type=302'
    abbrlink: cfc584dd

    date: 2024-09-30 20:14:35

报错异常中信息没有显示错误行号

应该是PDB没有加载，但PDB文件有生成，且配置都是正确的

考虑到A.C.dll好像是通过反射还是怎么样的加载的，网上这种方式是不会加载PDB，但原因在github issue没搜到。

  1. 导出dump

    设置符号路径为bin下

  2. 打开详细输出

    !sym noisy

  3. 切换到业务所在线程

    ~*kv，切换后reload一下

    ~58s

  4. 打印当前堆栈

    :058> kv
# Child-SP          RetAddr               : Args to Child                                                           : Call Site
00 00000088`014ff4a8 00007ff8`0372bd3b     : 00000000`00000000 00000000`00000000 00000000`00000000 0000026b`8e08ad90 : ntdll!NtReadFile+0x14
01 00000088`014ff4b0 00007ffe`ba43e021     : 0000026b`f23699b8 00000000`00000000 00000000`00000000 00000088`014ff638 : KERNELBASE!ReadFile+0x7b
02 00000088`014ff520 00007fff`1eb6cd13     : 0000026b`f23694e0 00000000`00000000 00000000`00000001 00007ffe`ba43e04c : 0x00007ffe`ba43e021
03 00000088`014ff600 00007fff`1eb6bfb8     : 0000026b`f2369990 00007fff`14e83e3a 00000088`014ff620 00007ffe`ba43e021 : System_IO_Pipes!System.IO.Pipes.PipeStream.ReadCore+0x73 [/_/src/libraries/System.IO.Pipes/src/System/IO/Pipes/PipeStream.Windows.cs @ 300] 
04 00000088`014ff670 00007fff`14f16b9c     : 00000000`00000000 00007fff`14e8c21a 0000026b`f23694e0 00007fff`14f2dd0f : System_IO_Pipes!System.IO.Pipes.PipeStream.Read+0xf8 [/_/src/libraries/System.IO.Pipes/src/System/IO/Pipes/PipeStream.Windows.cs @ 35] 
05 00000088`014ff6f0 00007ffe`ba43e30f     : 0000026b`f2369418 0000026b`f23698c0 00000088`014ff7e0 0000026b`f2369418 : System_Private_CoreLib!System.IO.BinaryReader.ReadBytes+0x13c
06 00000088`014ff750 00007ffe`ba43e152     : 0000026b`f2368f60 0000026b`f2369840 00000000`00000058 00000000`00000000 : Microsoft_Diagnostics_NETCore_Client!Microsoft.Diagnostics.NETCore.Client.IpcHeader.Parse+0x5f [_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcHeader.cs @ 55] 
07 00000088`014ff790 00007ffe`ba438e3b     : 0000026e`32341b20 0000026c`72392ae8 00000000`00000000 00007fff`14e8c21a : Microsoft_Diagnostics_NETCore_Client!Microsoft.Diagnostics.NETCore.Client.IpcMessage.Parse+0x62 [_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcMessage.cs @ 115] 
08 00000088`014ff7f0 00007ffe`ba438cd0     : 0000026b`f2368f00 00007ffe`ba437a45 00000000`00000000 00000000`00000004 : Microsoft_Diagnostics_NETCore_Client!Microsoft.Diagnostics.NETCore.Client.IpcClient.SendMessageGetContinuation+0x6b [_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcClient.cs @ 46] 
09 00000088`014ff850 00007ffe`ba436d83     : 0000026b`f2367e48 00007ffe`b845e990 0000026c`72392a98 0000026d`3245ba88 : Microsoft_Diagnostics_NETCore_Client!Microsoft.Diagnostics.NETCore.Client.IpcClient.SendMessage+0x30 [_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcClient.cs @ 25] 
0a 00000088`014ff8b0 00007ffe`ba435b08     : 0000026b`f2367fb0 00000000`00000004 0000026c`72392a98 00000000`00000000 : Microsoft_Diagnostics_NETCore_Client!Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.WriteDump+0x73 [_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsClient/DiagnosticsClient.cs @ 176] 
0b 00000088`014ff900 00007ffe`ba42e2ae     : 0000026b`f2367e48 0000026b`f2360660 00000000`00000001 00000088`014ff850 : a_26b90f60000!a.c+0xb8
0c 00000088`014ff9e0 00007ffe`ba42dbd5     : 0000026d`3245af70 0000026d`3245ba00 0000026d`3245ba88 0000026d`3245ba88 : a_26b90f60000!a.c.doWork+0x10e
0e 00000088`014ffac0 00007fff`14e5dde9     : 0000026b`8df544d0 00000000`00000000 0000026b`8df544d0 00000fff`e2c3346e : System_Private_CoreLib!System.Threading.Thread.StartHelper.Callback+0x39 [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Thread.cs @ 42] 
0f 00000088`014ffb00 00007fff`14e52f5a     : 00000088`014ffca0 00000000`00000020 00000000`00000000 00000000`00000002 : System_Private_CoreLib!System.Threading.ExecutionContext.R

.cs @ 176]
0b 00000088014ff900 00007ffeba42e2ae : 0000026bf2367e48 0000026bf2360660 0000000000000001 00000088014ff850 : a_26b90f60000!a.c+0xb8
0c 00000088014ff9e0 00007ffeba42dbd5 : 0000026d3245af70 0000026d3245ba00 0000026d3245ba88 0000026d3245ba88 : a_26b90f60000!a.

这两句没有显示源代码。

  1. 使用.lines -e

    The .lines command enables or disables support for source-line information.
    .lines命令启用或禁用对源行信息的支持。

    .lines（切换源行支持）- Windows 驱动程序 |微软学习 — .lines (Toggle Source Line Support) - Windows drivers | Microsoft Learn

    其中有很多命令可以参考，如# .lastevent

    DBGHELP: .\symbols\x\A.dbg - path not found
DBGHELP: A.x missing debug info.  Searching for pdb anyway
DBGHELP: Can't use symbol server for A.pdb - no header information available

发现有一个pdb没找到。使用chksym检查，发现a.c.pdb and a.c.dll是匹配的，且有找到，路径也对。

!chksym a.c.dll

 pdb sig: 9A3E5FD8-9F1C-4CAB-B865-D03AF681005E
          age: 1

MATCH: a.c.pdb and a.c.dll

对比了一个，.lines要找的是a.pdb，而 chksym检查dll的pdb是a.c.pdb。有点相似，但我没有用过a.c这个文件。

然后我将a.c.pdb重命名成a.pdb，然后.reload一下，行就显示了！！！

结论：可能这个a.c.dll 是通过比较特殊的方式反射进入的，且没有.dll后缀。

666

使用lm 再次查看，发现a.c.dll 是带着一串数字后缀a_26b90f60000,输入lmDvma_26b90f60000发现

0000026b`904e0000 0000026b`90f37400   IGeekFan_AspNetCore   (deferred)             
0000026b`90f60000 0000026b`9101c400 a_26b90f60000  C (service symbols: CLR Symbols with PDB: C:\ProgramData\Dbg\sym\

```bash
lmDvma_26b90f60000

Image path:
Image name:

Image name 不一样

AppDomain.CurrentDomain.Load

Assembly.CreateInstance 方法创建了类

好像是使用了Assembly.Load？？这个不清楚是不是这个原因

| Load(String) | 用指定的名称加载程序集。 |
| ——————————————————————————————————————————————————– | ———— |

c# - 从.net core 2.0中动态加载的程序集调试代码 - 代码日志 — c# - Debugging code from dynamically loaded assembly in .net core 2.0 - Stack Overflow

[[API 提案] 一种在使用 Assembly.LoadFrom() 加载的程序集上强制加载程序集 pdb 的方法 · 问题 #44743 · dotnet/runtime — [API Proposal] A way to force load assembly pdbs on assemblies loaded with Assembly.LoadFrom() · Issue #44743 · dotnet/runtime (github.com)](https://github.com/dotnet/runtime/issues/44743)

I think basically the only thing in .NET Core Framework which is affected by having (or not) PDBs is stack trace generation in exceptions and similar places and then managed debuggers for cases where code is loaded from memory. @noahfalk is there a way to influence the automatic PDB loading which happens when generating stack traces for example?
我认为基本上 .NET Core Framework 中唯一受有（或没有）PDB 影响的是异常和类似位置中的堆栈跟踪生成，然后是从内存加载代码的情况下的托管调试器。有没有办法影响例如生成堆栈跟踪时发生的自动 PDB 加载？

As for this particular API, if we were to add functionality like this, I think it should go to AssemblyLoadContext.LoadFromAssemblyPath. Assembly.LoadFrom is problematic already because it always loads into the default load context (but the fact it does that is not obvious), which can lead to unexpected behaviors if used from libraries and similar. For this reason we're trying to encourage people to use the AssemblyLoadContext.LoadFromAssemblyPath instead which is explicit in which load context it works on - at least it makes people think about load contexts when loading assemblies.
至于这个特定的API，如果我们要添加这样的功能，我认为它应该去 AssemblyLoadContext.LoadFromAssemblyPath 。 Assembly.LoadFrom已经存在问题，因为它总是加载到默认加载上下文中（但事实上它这样做并不明显），如果从库和类似库中使用，可能会导致意外行为。出于这个原因，我们试图鼓励人们使用 AssemblyLoadContext.LoadFromAssemblyPath 相反，它在哪个加载上下文中工作是明确的 - 至少它让人们在加载程序集时考虑加载上下文。

docker-net-dump-导出
代码覆盖率测试