Voici la situation:Aide postmorten le débogage d'un mode mixte application Win32
Contexte
J'ai une application en mode mixte .NET/natif développé dans Visual Studio 2008.
Ce que je veux dire par le mode mixte est que le front-end est écrit en C++ .NET qui appelle dans une bibliothèque C++ native. Le code natif fait la majeure partie du travail dans l'application, y compris le lancement de nouveaux threads comme il le requiert. Le code .NET est uniquement à des fins d'interface utilisateur (gagner des formulaires).
J'ai une version de version d'application qui s'exécute sur l'ordinateur d'un testeur.
Les bibliothèques natives ont été compilées avec des optimisations complètes, mais aussi avec le débogage activé (le "Format des informations de débogage" a été défini sur "Program Database"). Cela signifie que j'ai les symboles de débogage pour l'application dans un fichier PDB.
Le problème
De toute façon, l'un des testeurs est d'avoir un problème avec l'application où il se bloque parfois sur XP. J'ai été en mesure d'obtenir le mini-accident de l'accident en utilisant le Dr Watson pour plusieurs courses. Quand je débogue dedans (en utilisant le minidump - je ne suis pas en train de déboguer la vraie application), tous les symboles de débogage sont chargés correctement: Je peux voir la trace complète de la pile de tous les threads natifs correctement. Les autres threads (qui sont vraisemblablement les threads .NET) n'ont pas de trace de pile, mais ils me montrent au moins quelle DLL a démarré le thread (c'est-à-dire ntdll.dll).
Il rapporte correctement le fil qui échoue ("exception non gérée à 0x0563d652 dans l'utilisateur (5) .dmp: 0xC0000005: violation d'accès lecture emplacement 0x00000000).
Cependant quand je vais dans le fil, il ne montre rien utile. Dans la trace de la pile, il y a une seule entrée qui a juste l'adresse mémoire "0563d652()" (pas même "ntldll.dll")
Quand je vais en désassemblage, cela montre juste une section aléatoire d'environ 30 instructions. L'un ou l'autre côté de l'adresse mémoire est juste "???" Il semble presque qu'il ne fasse pas partie de mon code source (votre binaire n'est-il pas chargé séquentiellement en mémoire? mi ddle de nulle part?).
Mes questions
Donc, fondamentalement, mes questions sont threfold.
1) Quelqu'un peut-il expliquer le manque d'informations du débogueur?
2) Ayant à l'esprit, je ne peux pas montrer l'erreur dans mon code, quelqu'un peut-il suggérer une raison de l'échec
3) Puis-je faire autre chose pour me aider à diagnostiquer ce problème actuel dans le avenir?
Aide!
John
Mise à jour:
Voici la décharge de la pile pour le fil défectueux de WinDBG
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 099bf414 02d0e7fc 0x563d652
01 00000000 00000000 0x2d0e7fc
Bizarre hein? N'affiche même pas une DLL.
Est-il possible que j'ai corrompu la pile/tas d'une façon ou d'une autre ce qui a causé un thread juste corrompu ...?
Non, à l'aide du débogueur intégré Visual Studio 2008. Je vais essayer WinDbg - bonne suggestion, merci. – John
Même résultat avec WinDBG j'ai peur. En ce qui concerne SOS, il est recommandé d'utiliser un vidage complet au lieu d'un minidump (ce qui est tout ce que j'ai). Va voir si je peux obtenir une décharge complète pour essayer. – John
Eh bien, minidump pourrait également être un vidage complet dans un sens - dépend des options avec lesquelles il a été créé. d'ailleurs, en utilisant le windbg est toujours une bonne idée; o) – deemok