J'ai une application Crashing .NET 2.0 qui ne donne aucune exception ni autre type de message lorsque l'application se bloque. J'attrape l'événement Application.ThreadException et rien n'est reçu lors de la collision. Après avoir couru quelques jours, l'application est partie! Aucun message dans le journal des événements Windows, aucun fichier de vidage ou autre chose ... J'ai essayé d'exécuter l'application sur plusieurs PC, mais après quelques jours, le problème apparaît.
L'application communique avec un autre PC via une connexion TCP / IP, et toutes les données sont valides tout le temps, pas de connexions cassées ou autre. Il y a suffisamment de mémoire, également au moment de la crash, etc. L'espace disque n'est pas non plus un problème. Il n'y a pas d'option pour passer à .NET 4.0.
À ce moment, l'application est exécutée sous Windbg, alors j'espère que cela donnera des informations.
Si vous avez une expérience avec cela ou si vous avez des conseils ou des outils utiles, faites-le moi savoir!
4 Réponses :
Lorsqu'une application .NET sort soudainement sans aucune invite d'erreur ou les manipulateurs d'exception non gérée, il est très probable que votre application se heurte à un débordement de la pile. Cela mettra rapidement fin au processus dans de nombreux cas sans exécuter de gestionnaires.
N'y a-t-il aucun moyen d'obtenir une sorte de trace ou quelque chose dans le journal des événements? Même "je suis mort"?
@John, il devrait apparaître dans le journal des événements mais il suffira simplement de dire "débordement de pile". J'ai constaté que Windbg est généralement meilleur que vs ici que cela se brisera et vous donnera une chance de voir la pile pendant que VS est plus susceptible de sortir avec soudainement tout en débogage.
Je m'attendais à quelque chose dans le journal des événements, mais l'Op a dit qu'il n'y avait rien. Quelle source d'événement, ID et journal seraient utilisés?
@John Je ne crois pas qu'une entrée dans le journal des événements soit garantie. Mais c'est une zone que je n'ai pas beaucoup de profondeur dans
essayez AppDomain.unhandleXception . Application.threadException ne soulève que lorsqu'une exception se produit sur les threads de l'interface utilisateur.
Si vous utilisez TCP / IP, vous utilisez probablement des threads. Si un thread meurt d'une exception non gérée, très courant lorsque vous appelez endxxxxx (), votre application se termine. Cela peut être silencieux si la déclaration d'erreur de Windows est désactivée sur la machine, non rare sur les serveurs. Au moins attraper ObjectDisposeceptionException pour que vous puissiez faire face à une connexion qui se déconnecte brusquement ou est fermée de force.
et oui, écrivez un gestionnaire d'événements pour AppDomain.CurrentDomaine.unhandledexception, souscrivez-le dans votre méthode principale (). Connectez-vous ou affichez la valeur de E.ExceptionObject.Tostring () afin que vous puissiez dire exactement ce qu'il va de mourir.
J'ai eu ce problème.
J'avais écrit une application .NET qui effectuait une émulation de Keystroke sur d'autres applications. Je laisserais courir toute la nuit dans l'espoir de trouver tout mon travail au matin. C'était juste parti. Il a écrit un journal chaque fois qu'il est entré et sorti une routine pour pouvoir voir exactement ce qu'elle avait fait. Rien, pas de journalisation d'exception. Il suffit de travailler le travail de travail. et Ensuite, rien.
s'avère que c'était parce que j'utilisais un tas d'appels d'API et je les appelais très fréquemment. Cela causait une sorte de fuite de mémoire, probablement dans l'espace de travail de mon application.
Et ainsi de suite, jusqu'à ce que tout le travail soit fait! En désordre et frustrant mais finit par travailler tout à fait :) Je suis sûr qu'il y a beaucoup beaucoup meilleure façon de le faire. Je n'étais probablement pas le marshaling mon API Com appels correctement ou autre chose.
Mais il semble que la fermeture de l'application et le redémarrage était la mémoire de la mémoire (avec les fuites) et la laissant commencer à nouveau.
Peut-être pas d'utilisation dans votre Cirsumstance mais c'est mon histoire. Amen.