堆栈内存溢出
  简体   繁体   English

未加载ngen-ed程序集的符号

[英]Symbols for ngen-ed assemblies are not loaded

 原文  2016-11-10 09:20:16  5   2    .net/ debugging/ windbg/ symbols/ pdb

问题描述

I am trying to decode the following call stack line from procmon: 我试图从procmon解码以下调用堆栈行： 

29  System.Management.Automation.ni.dll System.Management.Automation.ni.dll + 0x897a0a  0x7fee2ae7a0a   C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll

As you can see there is an NGEN-ed assembly in it: System.Management.Automation.ni.dll . 正如您所看到的，其中有一个NGEN-ed程序集： System.Management.Automation.ni.dll 。 I created a pdb file for it with ngen createpdb : 我使用ngen createpdb为它创建了一个pdb文件： 

PS> ngen createpdb c:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll c:\symbols\ngen

Successfully generated PDB for native assembly 'c:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a8698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll'.
PDB generated in directory c:\symbols\ngen\System.Management.Automation.ni.pdb a86698074f28597f1fc5ceabfed6fed61\

My Symbol path in the _NT_SYMBOL_PATH variable is: _NT_SYMBOL_PATH变量中的符号路径是： 

SRV*C:\symbols\ngen*;SRV*C:\symbols\dbg*http://referencesource.microsoft.com/symbols;SRV*C:\symbols\dbg*http://msdl.microsoft

.com/download/symbols .COM /下载/符号

But I can still see that the newly generated symbol file is not loaded for the assembly: 但我仍然可以看到没有为程序集加载新生成的符号文件： 

PS a86698074f28597f1fc5ceabfed6fed6> dbh -n .\System.Management.Automation.ni.dll
verbose mode on.
DBGHELP: No header for .\System.Management.Automation.ni.dll.  Searching for image on disk
DBGHELP: C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll - OK
SYMSRV:  C:\symbols\ngen\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb - file not found
SYMSRV:  C:\tools\diag\Debugging Tools for Windows\x64\sym\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb - file not found
SYMSRV:  C:\symbols\ngen\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb not found
SYMSRV:  C:\tools\diag\Debugging Tools for Windows\x64\sym\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb not found
DBGHELP: System.Management.Automation.ni - public symbols
        C:\symbols\dbg\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb

I've checked the debug header in the .dll file and it has two entries: 我检查了.dll文件中的调试头，它有两个条目： 

PS> dumpbin /headers .\System.Management.Automation.ni.dll
...
  Debug Directories
        Time Type        Size      RVA  Pointer
    -------- ------- -------- -------- --------
    56BEFBC1 cv           11C 01F200A4  1F1E8A4    Format: RSDS, {A8669807-4F28-597F-1FC5-CEABFED6FED6}, 1, System.Management.Automation.ni.pdb
    56BEFBC1 cv            39 01F201C0  1F1E9C0    Format: RSDS, {6B8B8F14-D056-4CB8-93B6-E84B43CAE67B}, 1, System.Management.Automation.pdb
...

The A8669807-4F28-597F-1FC5-CEABFED6FED6 entry is first, but seems that is never used by dbh (or actually dbghelp), and it is only looking for the 6B8B8F14-D056-4CB8-93B6-E84B43CAE67B . A8669807-4F28-597F-1FC5-CEABFED6FED6条目是第一个，但似乎从未被dbh（或实际上是dbghelp）使用，它只是在寻找6B8B8F14-D056-4CB8-93B6-E84B43CAE67B 。 I tried setting the symbols path only to the C:\\symbols\\ngen, but it didn't help - the symbol file was still not found. 我尝试将符号路径仅设置为C：\\ symbols \\ ngen，但它没有帮助 - 仍未找到符号文件。

My dbghelp version is: 10.0.10240.16399 我的dbghelp版本是：10.0.10240.16399

Can someone point me what I'm doing wrong here? 有人能指出我在这里做错了什么吗？

EDIT 1: 编辑1：

Seems that the dbh verbose output is pretty consistent with what procmon is showing: 似乎dbh详细输出与procmon显示的内容非常一致：

Process Monitor的屏幕截图

EDIT 2 (to Hans answer) 编辑2（汉斯回答）

My application is actually a Powershell script. 我的应用程序实际上是一个Powershell脚本。 I listed .NET modules for powershell.exe in Process Hacker and found that it's using System.Management.Automation.dll version 3.0.0: 我在Process Hacker中列出了powershell.exe的.NET模块，发现它使用的是System.Management.Automation.dll 3.0.0版：

加载程序集的截图

I suppose that the original assembly is located in GAC: c:\\Windows\\Microsoft.NET\\assembly\\GAC_MSIL\\System.Management.Automation\\v4.0_3.0.0.0__31bf3856ad364e35\\System.Management.Automation.dll 我想原始程序集位于GAC中：c：\\ Windows \\ Microsoft.NET \\ assembly \\ GAC_MSIL \\ System.Management.Automation \\ v4.0_3.0.0.0__31bf3856ad364e35 \\ System.Management.Automation.dll

which apparently was created for .NET 4.0: 这显然是为.NET 4.0创建的： 

PS temp> corflags c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.6.1055.0
Copyright (c) Microsoft Corporation.  All rights reserved.
Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x9
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 1

Now, I've also looked for any other System.Management.Automation assemblies in the NativeImages folder, but there is only 1 for .NET 4.0 64-bit: 现在，我还在NativeImages文件夹中查找了任何其他System.Management.Automation程序集，但.NET 4.0 64位只有1个：

截图

The .aux header also seems to mention only the 3.0.0 version. .aux标题似乎也只提到3.0.0版本。 Notice also that the .ni file has TWO PDB files referenced in the Debug header. 另请注意，.ni文件在Debug头中引用了两个PDB文件。 One of them is the one I want. 其中一个是我想要的。

EDIT 3 (fuslogvw) 编辑3（fuslogvw）

As advised by Hans I enabled the Fusion log for Native Images. 根据Hans的建议，我启用了本地图像的Fusion日志。 Below is the snippet showing the path from which the Automation assembly is loaded: 下面是显示加载自动化程序集的路径的代码段： 

... Pre-bind state information ...
LOG: DisplayName = System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
 (Fully-specified)
LOG: Appbase = file:///C:/Windows/System32/WindowsPowershell/v1.0/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = powershell.exe
Calling assembly : Microsoft.PowerShell.ConsoleHost, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
...
LOG: Start validating all the dependencies.
LOG: [Level 1]Start validating native image dependency mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating native image dependency System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: [Level 1]Start validating native image dependency System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency System.Configuration.Install, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Level 1]Start validating IL dependency System.Transactions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency Microsoft.Management.Infrastructure.Native, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: [Level 1]Start validating IL dependency System.Management, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Level 1]Start validating IL dependency System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Level 1]Start validating IL dependency System.DirectoryServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Level 1]Start validating IL dependency System.Runtime.Serialization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency Microsoft.CSharp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Level 1]Start validating IL dependency System.ServiceModel.Internals, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: [Level 1]Start validating IL dependency System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency System.Numerics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Level 1]Start validating IL dependency System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Level 1]Start validating IL dependency SMDiagnostics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
Native image has correct version information.
LOG: Validation of dependencies succeeded.
LOG: Bind to native image succeeded.
Attempting to use native image C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll.
Native image successfully used.

2 个解决方案

解决方案1
 8  2016-11-10 20:31:38

Unfortunately, I think it is a bug in either dbghelp or ngen. 不幸的是，我认为这是dbghelp或ngen中的一个错误。 I created a Test.dll assembly and ngen-ed it: 我创建了一个Test.dll程序集并对其进行了编译： 

ngen install Test.dll

It landed in: 它降落在：

c:\\Windows\\assembly\\NativeImages_v4.0.30319_64\\Test\\7dece650b5d91e7ac799a78b3d1b7c59\\Test.ni.dll

as expected. 正如所料。 I also created symbols for it: 我也为它创建了符号： 

ngen createpdb c:\Windows\assembly\NativeImages_v4.0.30319_64\Test\7dece650b5d91e7ac799a78b3d1b7c59\Test.ni.dll c:\symbols\ngen

When I checked the debug headers I got two again: 当我检查调试头时，我又得到了两个： 

> dumpbin /headers c:\Windows\assembly\NativeImages_v4.0.30319_64\Test\7dece650b5d91e
7ac799a78b3d1b7c59\Test.ni.dll
  Debug Directories
        Time Type        Size      RVA  Pointer
    -------- ------- -------- -------- --------
    5824BFEB cv           11C 00003D40     1F40    Format: RSDS, {7DECE650-B5D9-1E7A-C799-A78B3D1B7C59}, 1, Test.ni.pdb
    5824BFEB cv           11C 00002E5C     205C    Format: RSDS, {F32EB2CE-973C-438F-BB78-A24D9971C194}, 1, C:\temp\Test.pdb

When I tried to load symbols for the Test.ni.dll, dbh tried to load .pdb file with the F32EB2CE-973C-438F-BB78-A24D9971C194 signatue (which is wrong). 当我尝试为Test.ni.dll加载符号时，dbh尝试使用F32EB2CE-973C-438F-BB78-A24D9971C194 signatue加载.pdb文件（这是错误的）。 I then opened a HEX editor, and replaced the order in which the debug directories are listed in the PE file (I found them by timestamps :)): 然后我打开了一个HEX编辑器，并替换了PE文件中列出调试目录的顺序（我通过时间戳找到它们:)：

在此输入图像描述

Now, dumpbin showed them in a different order: 现在，dumpbin以不同的顺序显示它们： 

Time     Type        Size      RVA  Pointer
-------- ------- -------- -------- --------
5824BFEB cv           11C 00002E5C     205C    Format: RSDS, {F32EB2CE-973C-438F-BB78-A24D9971C194}, 1, C:\temp\Test.pdb
5824BFEB cv           11C 00003D40     1F40    Format: RSDS, {7DECE650-B5D9-1E7A-C799-A78B3D1B7C59}, 1, Test.ni.pdb

and dbh started working correctly: 和dbh开始正常工作： 

> dbh -n -s:SRV*c:\symbols\ngen* c:\Windows\assembly\NativeImages_v4.0.30319_64\Test\
7dece650b5d91e7ac799a78b3d1b7c59\Test.ni.dll
verbose mode on.
DBGHELP: Symbol Search Path: SRV*c:\symbols\ngen*
Symbol Search Path: SRV*c:\symbols\ngen*
DBGHELP: No header for c:\Windows\assembly\NativeImages_v4.0.30319_64\Test\7dece650b5d91e7ac799a78b3d1b7c59\Test.ni.dll.  Searching for image on disk
DBGHELP: c:\Windows\assembly\NativeImages_v4.0.30319_64\Test\7dece650b5d91e7ac799a78b3d1b7c59\Test.ni.dll - OK
DBGHELP: Test.ni - public symbols & lines
        c:\symbols\ngen\Test.ni.pdb\7DECE650B5D91E7AC799A78B3D1B7C591\Test.ni.pdb
Test.ni [1000000]:

I created an issue on connect and kindly ask you to upvote it. 我在连接上创建了一个问题 ，请您对它进行upvote。

解决方案2
 0  2018-02-13 00:54:32

The answer above is correct - It is a known issue at Microsoft. 上面的答案是正确的 - 这是微软的一个已知问题。

Depending on what you are trying to accomplish you might be able to use commands in SOS as a workaround. 根据您要完成的任务，您可以在SOS中使用命令作为解决方法。 For example the !ip2md command resolves IPs into method names. 例如，！ip2md命令将IP解析为方法名称。 https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension

暂无
暂无

声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 我们可以拆解（使用ILDasm）NGen-ed组件吗？ - Can we disassemble (using ILDasm) an NGen-ed assembly? 确定是否正在使用GAC'ed和NGen'ed程序集 - Determine if GAC'ed & NGen'ed assemblies are being used 分发NGEN之前的程序集是否有意义？ - Does it make sense to distribute pre-NGEN-ed assemblies? 如何安装具有NGEN版本的二进制文件的IronPython 2.0？ - How do I install IronPython 2.0 with NGEN'ed binaries? 使用NGEN创建的.NET本机映像未加载 - .NET native images created with NGEN are not loaded 如何衡量在NGen之前正确重新定义.NET程序集的效果？ - How to measure the effect of correctly rebasing .NET assemblies before NGen? 什么时候加载程序集？ - When exactly are assemblies loaded? 动态加载程序集的兼容性 - Compatibility of dynamically loaded assemblies .NET JIT在可共享页面中的程序集 - .NET JIT'ed assemblies in sharable pages 程序集如何加载到AppDomain中？ - How are assemblies loaded into the AppDomain?
相关标签
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM