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

У меня есть смешанное приложение 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 и версии SP .NET.Я видел это в основном для собственных изображений WPF.

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

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

Iзабыл упомянуть, что я боролся с подобной проблемой с различными версиями mscordacwks dll.Чтобы использовать 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 не может быть использован, ...

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

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

Ответы [ 2 ]

5 голосов
/ 04 января 2011

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

Причина, по которой WinDbg хочет, чтобы исходные библиотеки DLL в дополнение к символам, заключалась в том, что для того, чтобы мини-дамп был небольшим, большая часть образа памяти была оставлена. В этом случае на компьютере, на котором был создан мини-дамп, использовалась другая версия платформы .NET, чем та, которая установлена ​​на компьютере, на котором запускается 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) \ Справочные сборки \ Microsoft \ Framework
  • C: \ Program Files \ Справочные сборки \ Microsoft \ Framework

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

1 голос
/ 17 февраля 2012

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

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

>!IP2MD 564618E3 
...