Comment puis-je trouver la source d'une exception non gérée?

Question

J'ai une application WinForms où je veux être en mesure de fournir une fonction d'édition HTML. J'ai donc traduit HTML Writer de Lutz Roeder de C # en VB.NET, et a été converti d'une fenêtre former dans un contrôle utilisateur personnalisé, qui est maintenant hébergé dans un formulaire enfant MDI.

Tout fonctionne bien jusqu'à ce que je ferme le parent MDI, auquel cas il se bloque et je ne peux pas piéger l'exception.

J'ai isolé le contrôle de l'éditeur dans une petite application WinForms de vanille qui ne fait rien d'autre, et vérifié que le problème persiste.

J'ai également allumé code non managé Debugging (j'utilise VS2010, compilation pour x86 et Framework 3.5), et tous Tracez votre I est ceci:

Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.

La seule chose autre chose que j'ai remarqué est que si je laisse un long intervalle après l'ouverture du formulaire contenant l'éditeur, il ne tombe pas en panne.

Ce que j'apprécie vraiment est quelques idées sur la façon d'aller chercher ce problème. Il peut être bien sûr que je l'ai fait une erreur dans le C # pour la conversion VB, mais je me bats pour savoir où chercher.

Modifier :

J'ai exécuté l'application avec le débogueur attaché, et il ne me donne pas quelque chose d'utile.

Tout ce que je get est le Windows de l'application a cessé de fonctionner "message, avec cela dans les détails du problème:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: HtmlEditorMdi.exe
  Application Version:  1.0.0.0
  Application Timestamp:    4cfb74c7
  Fault Module Name:    mscorwks.dll
  Fault Module Version: 2.0.50727.4952
  Fault Module Timestamp:   4bebd49a
  Exception Code:   c0000005
  Exception Offset: 000022b5
  OS Version:   6.1.7600.2.0.0.256.1
  Locale ID:    2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Je peux voir que c'est une violation d'accès, mais même si je Test> Exceptions> Exceptions Win32 , et les tiques c0000005 , je ne reçois rien utile lorsque il se casse -. juste 'aucune source disponible

Answer 1

Le premier message que vous avez cité est produit par le gestionnaire de tas de Windows quand il découvre que la structure du tas interne est détruite. Il affiche que diagnostic quand il voit qu'un débogueur est attaché. Le 2ème bloc cité est ce qui se passe quand il contourne le diagnostic (pas débogueur ci-joint), il bombes sur une exception du matériel quand il essaie de libérer de la mémoire dans le tas corrompu de toute façon.

Le problème avec la corruption tas est que le vrai mal est fait depuis longtemps avant que le diagnostic est généré. Vous pouvez voir une trace de la pile menant au diagnostic dans la fenêtre Call Stack, vous devez activer le serveur de symboles Microsoft pour obtenir des symboles significatifs pour les fonctions Windows. Mais il ne vous dira rien d'utile sur le code qui a vraiment causé le dommage, qui nécessite une machine de temps.

Ce genre de corruption tas est toujours causée par le code non managé. L'exception AccessViolation est un fléau bien connu C / C ++ programmeurs et une raison très importante pour laquelle le code managé est devenu populaire. Alors que le code source Lutz est tout géré, il contient un beaucoup de l'interface déclarations P / Invoke et COM. Il n'y a pas de bonne façon de les déboguer, vous ne disposez pas du code source.

Obtenir une de ces déclarations subtilement mal lorsque vous les convertis en VB.NET est certainement une façon cela pourrait se produire. Il pourrait aussi bien être que le bug était toujours là, mais maintenant cabra juste sa tête hideuse. Quel chanceux êtes-vous. BTW, je ne pense pas que le code est propre, forcer 64 bits pour exécuter en 32 mode pour une solution rapide possible. Pour votre principal projet EXE: Propriétés du projet +, onglet Compile, faites défiler vers le bas, Options avancées de compilation, CPU cible = x86. Ceci ne concerne que si vous exécutez sur une version 64 bits de Windows.

En dehors de cela, je vous recommande simplement d'utiliser le projet C # en l'état. Le mélange des langues dans une solution est un scénario très bien pris en charge dans .NET.

Answer 2

Le windbg débogueur est le « gros canon » pour ce genre de problème. Il peut souvent vous donner des indices en vous disant sur les exceptions traitées, etc. Le seul problème avec c'est que ce n'est pas facile à utiliser et a une courbe d'apprentissage très élevé.