Символы для сборных узлов не загружаются

Я пытаюсь декодировать следующую строку стека вызовов из procmon:

Как вы можете видеть, в нем есть сборка NGEN-ed: System.Management.Automation.ni.dll. Я создал файл pdb для него с ngen createpdb:

Но я все еще вижу, что новый созданный файл символов не загружен для сборки:

Я проверил заголовок отладки в DLL файле и имеет две записи:

Запись A8669807-4F28-597F-1FC5-CEABFED6FED6 является первой, но кажется, что она никогда не используется dbh (или фактически dbghelp), и она ищет только 6B8B8F14- D056-4CB8-93B6-E84B43CAE67B. Я попытался установить путь символов только к C:\symbols\ngen, но это не помогло - файл символов все еще не найден.

Может кто-нибудь указать мне, что я здесь делаю неправильно?

EDIT 1:

Похоже, что подробный вывод dbh вполне соответствует тому, что показывает procmon:

EDIT 2 (для ответа Ханса)

Мое приложение - это Powershell script. Я перечислил .NET-модули для powershell.exe в Process Hacker и обнаружил, что он использует System.Management.Automation.dll версии 3.0.0:

Я предполагаю, что исходная сборка находится в GAC: c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.03131bf3856ad364e35\System.Management.Automation.dll

Теперь я также искал любые другие сборки System.Management.Automation в папке NativeImages, но для .NET 4.0 64-бит существует только 1:

В заголовок .aux также упоминается только версия 3.0.0. Также обратите внимание, что .ni файл имеет TWO PDB файлы, указанные в заголовке Debug. Один из них - тот, который я хочу.

EDIT 3 (fuslogvw)

Как посоветовал Ханс, я включил журнал Fusion для Native Images. Ниже приведен фрагмент, показывающий путь, из которого загружается сборка Automation:

Ответы

Ответ 1

К сожалению, я думаю, что это ошибка в dbghelp или ngen. Я создал сборку Test.dll и ngen-ed:

ngen install Test.dll

Он приземлился в:

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

как ожидалось. Я также создал для него символы:

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

Когда я проверил заголовки отладки, я снова получил два:

> 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

Когда я попытался загрузить символы для Test.ni.dll, dbh попытался загрузить файл .pdb с сигнатурой F32EB2CE-973C-438F-BB78-A24D9971C194 (что неверно). Затем я открыл редактор HEX и заменил порядок, в котором каталоги отладки перечислены в PE файле (я нашел их по меткам времени:)):

Теперь дамббин показал их в другом порядке:

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

и 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]:

Я создал проблему при подключении и любезно попросите вас ее перенести.

Ответ 2

Правильный ответ - это известная проблема в Microsoft.

В зависимости от того, что вы пытаетесь выполнить, вы можете использовать команды в SOS в качестве обходного пути. Например, команда! Ip2md разрешает IP-адреса в именах методов. https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension