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

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

Когда я пытаюсь изучить минидамп с помощью команд !pe или !clrstack из sos-расширения Windbg, я часто получаю неполную информацию о кадрах стека из сборок 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:\Symbols*http://msdl.microsoft.com/download/symbols

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

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

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

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

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

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

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

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

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

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

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


.net wpf sos stack-trace minidump
person Peter Schneider    schedule 03.01.2011    source источник

Ответы (2)


arrow_upward
5
arrow_downward

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

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

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

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

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

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

person Rick Sladkey    schedule 04.01.2011
comment
Спасибо за ваше подробное объяснение! Но я все еще надеюсь, что есть другой способ... Я добавил некоторые подробности в свой вопрос в новом разделе. Обновление моего первоначального вопроса. - person Peter Schneider; 05.01.2011
comment
@Peter: Спасибо за дополнительную информацию. Ваше исследование показывает, что на самом деле вам нужны собственные образы (.ni.dll) для сборок, а не сами сборки. На самом деле WinDbg не нужна сборка, а только его PDB и собственный образ, а также PDB собственного образа. Я вижу только два решения. 1) Соберите все родные образы и сделайте их доступными для WinDbg, или 2) Соберите полный дамп вместо минидампа. Ни один из них не очень привлекательный. - person Rick Sladkey; 06.01.2011
comment
Жаль... Но еще раз спасибо за попытку помочь мне! Но так действительно кажется, что Microsoft оставляет нас в покое в этой области. Я думаю, мне нужно попробовать ваше решение 1). Знаете ли вы, как обойти проблему symstore, о которой я упоминал (попытка сохранить собственный образ не удалась)? - person Peter Schneider; 10.01.2011

arrow_upward
1
arrow_downward

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

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

>!IP2MD 564618E3
person josh poley    schedule 17.02.2012