Déboguer un crash après la sortie? (Après main retourné)

Question

Ceci est un bug assez impliqué, et j'ai essayé de trouver d'autres sources d'aide, mais pour des raisons que je ne comprends pas, "Program Crashes in Vista" n'est pas la requête la plus utile. Le problème que je rencontre est que le programme sur lequel je travaille - un logiciel graphique de visualisation de données multithread utilisant OpenGL et l'API Windows - plante après le retour de WinMain(). J'ai essayé de passer à travers la routine d'arrêt ainsi que d'examiner une trace de pile, et le dernier bit de code qui n'est pas assemblé est _crtExitProcess, où il se bloque dans l'appel ExitProcess (0) réel. Après cela, la trace de la pile montre kernel32.dll et quatre ntdll.dll, qui est l'endroit où il se bloque réellement.

Ce bug ne se produit que sur Vista, et le même code exact s'exécute normalement sous XP. Je ne peux vraiment pas penser à tout ce qui pourrait m'aider à déboguer ce problème, et le débogage de ce problème est quelque chose que je n'ai jamais vraiment appris. Toute aide serait appréciée.

Answer 1

Je l'ai fait un peu de creuser autour, et je l'ai trouvé quelques messages autour de cette suggérez vous n'êtes pas le seul à souffrir de cette:

• http://developer.nvidia.com/forums/index.php?showtopic=318
• http://objectmix.com/xml-soap/115379-problem-latest-ms-patches-msxml4-vista.html

en particulier, le second est d'intérêt, où Tom CHM mentionne:

W e crois que nous avons identifié la cause racine de notre accident, et l'ajout d'un destructeur virtuel à notre interface classe wrapper semble résoudre notre problème . Mais nous aimerions connaître la cause exacte de l'accident pour vérifier que nous n'avons pas simplement balayé le problème réel sous le tapis.

Le problème peut être avec un destructeur quelque part, ou son absence. Si vous avez un moyen d'attacher un débogueur et de passer par le processus d'arrêt, cela pourrait vous aider.

Vous pourriez vouloir lire tout le fil et voir s'il y a quelque chose que vous pouvez apprendre. C'est-à-dire, si vous n'avez pas déjà trouvé ces messages dans votre recherche, bien sûr.

Answer 2

Cela ressemble un peu à un problème avec un destructeur.

Vérifiez les objets détruits à l'arrêt. Ce seront principalement des objets globaux ou statiques. Regardez attentivement leurs destructeurs pour voir si quelque chose n'est plus valide. Dans un environnement multithread, il peut s'agir d'une condition de concurrence, où un objet est détruit alors qu'un autre thread l'utilise encore. Essayez d'écrire un journal lorsque des objets sont détruits. par exemple. WriteLog() doit ouvrir le fichier journal, écrire puis fermer le fichier pour s'assurer que le fichier est vidé. Utiliser un Mutex ou un CriticalSection pour éviter les conflits serait une bonne idée.

En regardant le journal après un accident peut vous donner quelques indices quant à ce qui se passe.