Вопрос: Как я могу получить полные трассировки стека для мини-масок в смешанном режиме, когда задействуются собственные изображения WPF?


У меня есть смешанное приложение C ++ / CLI, которое использует WPF. Сбои от наших клиентов сообщаются как minidumps на наш собственный сервер.

Когда я пытаюсь исследовать мини-накопитель с помощью команд! Pe или! Clrstack из windbg sos-extension, Я часто получаю неполную информацию для кадров стека из сборщиков WPF, например.

SP       IP       Function
0013E370 564618E3 PresentationFramework_ni!Unknown+0x1bf
0013E3A4 56461258 PresentationFramework_ni!Unknown+0x58
0013E3CC 5634C6D8 PresentationFramework_ni!Unknown+0x18
0013E3D8 55C04AA2 PresentationFramework_ni!Unknown+0x502
...

В этом случае декодирование трассировки стека также становится очень медленным.

Использование! Sym noisy показывает много сообщений из

SYMSRV:  C:\Symbols\PresentationFramework.ni.dll\488F142Edab000\PresentationFramework.ni.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/PresentationFramework.ni.dll/488F142Edab000/PresentationFramework.ni.dll not found
DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\PresentationFramework.ni.dll - file not found
DBGHELP: PresentationFramework.ni.dll not found in c:\Windows\System32
SYMSRV:  C:\Symbols\PresentationFramework.ni.dll\488F142Edab000\PresentationFramework.ni.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/PresentationFramework.ni.dll/488F142Edab000/PresentationFramework.ni.dll not found
DBGENG:  C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\PresentationFramewo#\9519494798a88867406b5755e1dbded6\PresentationFramework.ni.dll - Couldn't map image from disk.
SYMSRV:  C:\Symbols\PresentationFramework.dll\488F142E50e000\PresentationFramework.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/PresentationFramework.dll/488F142E50e000/PresentationFramework.dll not found
DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\PresentationFramework.dll - file not found
DBGHELP: PresentationFramework.dll not found in c:\Windows\System32
SYMSRV:  C:\Symbols\PresentationFramework.dll\488F142E50e000\PresentationFramework.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/PresentationFramework.dll/488F142E50e000/PresentationFramework.dll not found
DBGENG:  C:\WINDOWS\assembly\GAC_MSIL\PresentationFramework\3.0.0.0__31bf3856ad364e35\PresentationFramework.dll image header does not match memory image header.
DBGENG:  C:\WINDOWS\assembly\GAC_MSIL\PresentationFramework\3.0.0.0__31bf3856ad364e35\PresentationFramework.dll - Couldn't map image from disk.

я использовал

C: \ Windows \ System32, SRV * C: \ Символы * Http: //msdl.microsoft.com/download/symbols

как символ windbg и путь изображения.

Насколько я понял, это происходит только для родных образов .NET, если машина, на которой произошел сбой, и машина с отладчиком отличается в терминах версии Windows, .NET версии SP. Я видел его в основном для собственных изображений WPF.

Что я могу сделать, чтобы избежать этой проблемы?

Обновите мой первоначальный вопрос:

Я забыл упомянуть, что я боролся с аналогичной проблемой с разными версиями dll mscordacwks. Чтобы использовать SOS, версия mscordacwks.dll, используемая на компьютере с сбоем, необходима на компьютере для деградации. Поэтому я начал собирать различные версии этой DLL из разных комбинаций Windows и SP и помещать их на наш собственный сервер символов. Это, конечно, довольно неудобно, и тем более потому, что их нужно назвать по специальному соглашению (например, mscordacwks_x86_x86_2.0.50727.4952.dll).

Если я правильно понимаю ответ Рика снизу, я должен сделать что-то подобное для собственных образов сборков .NET, которые мы ссылаемся. Я пробовал это вручную с помощью одного примера (WindowsBase.ni.dll), но я не мог хранить эту DLL на нашем сервере символов легко. Кажется, что родные изображения не понимаемый symstore. Сообщение об ошибке от symstore:

SYMSTORE MESSAGE: Skipping file .\WindowsBase.ni.dll - not a known file type.

Поэтому я попытался поместить его в дополнительный каталог и добавил его в свой путь к символу или изображению, а затем SOS правильно декодировал кадры WindowsBase_ni.

Но все это кажется очень неприятной ручной настройкой: получение всех собственных изображений для различных версий .NET (что касается SP и обновлений безопасности), настраивая отладчик вручную, потому что symstore нельзя использовать, ...

Это действительно единственный способ?

Вероятно, это не такая проблема, если вы можете контролировать среду своих клиентов. Но это похоже на посмертный отладочный кошмар для orgnizations, которые создают приложения смешанного режима для больших пользовательских баз.


6


источник


Ответы:


Вывод символьного сервера показывает, что у него возникают проблемы при загрузке изображений , не символы  для этих изображений. Хотя Microsoft очень хорошо разбирается в том, что символы для всех выпущенных файлов попадают на сервер символов, в этом случае сами библиотеки DLL не были.

Причина, по которой WinDbg хочет, чтобы исходные библиотеки DLL были добавлены к символам, заключается в том, что для того, чтобы мини-блок был маленьким, большая часть изображения памяти не учитывается. В этом случае компьютер, на котором был создан minidump, использует другую версию .NET Framework, чем установлен на компьютере, на котором запущен WinDbg. Предположим, что компьютер с ошибкой имеет .NET3.5 под управлением Windows XP, а компьютер для анализа - .NET3.5, работающий в Windows 7. Вы думаете, что они будут той же самой версией, но Windows 7 получила собственную специальную версию .NET3.5 как можно видеть здесь:

Решение состоит в том, чтобы поместить библиотеки DLL, которые не могут быть загружены с сервера символов где-то на пути к символу. Однако я не вижу простого способа загрузки и установки только ссылочных сборок для конкретной версии .NET, которую вы хотите. Но поскольку вы подразумевали, что .loadby sos mscorwks работал для вас, то может быть, что DLL-файлы, которые вы хотите, уже находятся на компьютере.

Сначала вам нужно создать мини-накопитель вашей программы на тестовом компьютере, который вы можете контролировать, что создает эти симптомы в WinDbg. Я предлагаю попробовать Windows XP. Затем используйте Проводник процессов  найти полный путь к PresentationFramework.DLL на тестовом компьютере. Затем сравните размер файла и дату с DLL на вашем компьютере в таких местах, как:

  • C: \ Windows \ Microsoft.NET
  • C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework
  • C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework

Если вы можете найти файл, поместите папку, в которой он был найден, на пути к символу. Если вы не можете найти файл, вы можете прибегнуть к копированию недостающих файлов с тестового компьютера. Это не так плохо, как кажется, потому что не так много опубликованной версии .NET framework.


5



Это может быть код JITed, и в этом случае после загрузки СОС , вы можете использовать команду! IP2MD, чтобы получить имя функции (через IP):

SP       IP       Function
0013E370 564618E3 PresentationFramework_ni!Unknown+0x1bf
...

>!IP2MD 564618E3 

1