WinDbg无法读取Linux下.NET Core内存转储的调试目录

跨平台转储的内存映射局限性 #

Linux下用dotnet-dump生成的内存转储，只保存了进程运行时实际加载到内存的模块部分。而ELF格式的模块里，有些调试目录相关的段是仅存在于磁盘文件、不会被映射到进程内存的。WinDbg的!dh命令只能从转储里的内存数据去解析调试目录，自然读不到这些不在内存里的内容；但你把模块存回磁盘后，dumpbin是直接读取完整的ELF文件，能访问到所有段，所以正常。

WinDbg对ELF模块的命令支持局限 #

!dh本来是为Windows PE格式模块设计的，对ELF的支持属于后期扩展，逻辑上不如专门的ELF工具完善。它在处理转储里的ELF模块时，不会像dumpbin那样完整解析磁盘文件的结构，而是依赖内存中的映射数据，一旦调试目录不在内存映射区就会失败。

符号加载失败的连锁影响 #

调试目录里包含了符号文件的匹配信息（比如GUID、版本），WinDbg读不到这些信息，就没法自动匹配符号服务器上的文件，甚至手动指定符号路径也可能因为元数据缺失而无法关联。

• 把Linux机器上对应的原始.NET Core模块文件（比如libcoreclr.so、你的应用程序集）复制到Windows，然后在WinDbg里执行.reload /f <模块本地路径>，强制加载该模块的符号；
• 用!lmi <模块名>命令查看模块的基本标识信息，手动提取GUID和版本号，然后到符号服务器找到对应符号文件，手动加载。

内容的提问来源于stack exchange，提问作者mark