J'ai une application C++/CLI en mode mixte qui utilise WPF. Les plantages de nos clients sont signalés en minidumps sur notre propre serveur. Lorsque j'essaie d'explorer une minidump en utilisant les commandes! Pe ou! Clrstack de l'extension sb windbg, j'obtiens souvent des informations incomplètes pour les trames de pile des assemblages WPF, par ex. Le décodage de trace de pile devient également très lent dans ce cas. !Comment puis-je obtenir des traces de pile complètes pour les minidumps en mode mixte lorsque des images natives (WPF) sont impliquées?
L'utilisation SYM bruyant montre un grand nombre de messages de ce qui suit de
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.
je
c: \ Windows \ System32; SRV * C: \ Symbols * http: // msdl. microsoft.com/download/symbols
comme le symbole windbg et le chemin de l'image. Pour autant que je l'ai compris, cela n'arrive que pour les images natives .NET si la machine sur laquelle le crash est survenu et la machine avec le débogueur diffèrent en termes de version Windows, version .NET des SP. Je l'ai vu principalement pour les images natives WPF.
Que puis-je faire pour éviter ce problème?
mise à jour à ma première question:
j'ai oublié de mentionner que je me débattais avec un problème similaire avec différentes versions mscordacwks dll. Pour utiliser SOS, la version de mscordacwks.dll utilisée sur l'ordinateur en panne est nécessaire sur l'ordinateur de débogage. J'ai donc commencé à collecter différentes versions de cette DLL à partir de différentes combinaisons Windows et SP et à les mettre sur notre propre serveur de symboles. Cela est assez gênant, bien sûr, et plus encore car ils doivent être nommés en suivant une convention spéciale (par exemple, mscordacwks_x86_x86_2.0.50727.4952.dll).
Si je comprends bien la réponse de Rick ci-dessous, je dois faire quelque chose de similaire pour les images natives des assemblages .NET auxquels nous faisons référence. J'ai essayé ceci manuellement avec un exemple (WindowsBase.ni.dll) mais je ne pourrais pas stocker cette DLL sur notre serveur de symbole facilement. Il semble que les images natives ne sont pas comprises par symstore. Le message d'erreur de symstore est:
SYMSTORE MESSAGE: Skipping file .\WindowsBase.ni.dll - not a known file type.
donc j'ai essayé de le mettre dans un répertoire supplémentaire et ajouté à mon symbole ou le chemin d'image, puis SOS décodé les WindowsBase_ni trames correctement.
Mais tout cela semble être un travail fastidieux de configuration manuelle: obtenir toutes les images natives pour différentes versions .NET (qu'en est-il des SP et des mises à jour de sécurité), en configurant le débogueur manuellement car symstore ne peut pas être utilisé, ..
Est-ce vraiment le seul moyen?
Ce n'est probablement pas un problème si vous pouvez contrôler l'environnement de vos clients.Mais il ressemble à un cauchemar de débogage post-mortem pour les organisations qui construisent des applications en mode mixte pour les grandes bases d'utilisateurs.
Merci pour votre explication détaillée! Mais j'espère toujours qu'il y a une autre façon ... J'ai ajouté quelques détails à ma question dans la nouvelle section "Mise à jour de ma question initiale" –
@Peter: Merci pour les informations supplémentaires. Votre enquête montre que vous avez réellement besoin des images natives (.ni.dll) pour les assemblages, pas les assemblages eux-mêmes. En fait, WinDbg ne veut pas l'assemblage, seulement son PDB et son image native, et le PDB de son image native. Je ne vois que deux solutions. 1) Collectez toutes les images natives Relavent et rendez-les disponibles pour WinDbg, ou 2) Collectez un vidage complet au lieu de minidump. Aucun d'eux n'est très attrayant. –
Dommage ... Mais merci encore d'avoir essayé de m'aider! Mais il semble vraiment que Microsoft nous laisse seuls dans ce domaine. Je suppose que je dois essayer votre solution 1). Savez-vous comment contourner le problème de symstore que j'ai mentionné (en essayant de stocker l'image native échoue)? –