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

У меня есть приложение C ++ / CLI смешанного режима, которое использует WPF. Сбои наших клиентов регистрируются как минидампы на наш собственный сервер. Я часто получаю неполную информацию о кадрах стека из сборок 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.

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

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

Я забыл упомянуть, что я боролся с аналогичной проблемой с разными версиями 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, ...

Неужели это единственный способ?

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