Mon programme Delphi fonctionne en tant que service NT et fonctionne correctement depuis plus de 2 mois. Il s’arrête brusquement et génère un vidage sur incident:
Nom de l'application défaillante: tca_shctisvc_ip.exe, version: 7.1.0.1843, horodatage: 0x2a425e19 Nom du module défaillant: inconnu, version: 0.0.0.0, horodatage: 0x00000000 Code d'exception: 0xc0000005 Décalage d'erreur: 0x00000000
Il n’existait aucune adresse réelle sur laquelle travailler à partir des informations du journal des événements Windows. J'ai été en mesure de charger le mini-vidage dans WinDbg et il a été signalé qu'il y avait une exception, mais que des problèmes étaient rencontrés avec les cadres de pile. Un outil différent (Viewminidump) était capable de me montrer des piles de threads en cours d'exécution.
Où puis-je commencer à résoudre ce problème?
Le code d'exception 0xc0000005
est une violation d'accès. Un AV correspondant à l'erreur 0x00000000
signifie que quelque chose dans le code de votre service est en train d'accéder à un pointeur nil
. Il vous suffira de déboguer le service pendant son exécution pour savoir à quoi il accède. Si vous ne pouvez pas l'exécuter dans un débogueur, installez au moins un framework de consignation d'exception tiers, tel que EurekaLog ou MadExcept , pour savoir ce que faisait votre service au moment de la création du logiciel.
Je recevais le même problème avec une application différente,
Faulting application name: javaw.exe, version: 8.0.51.16, time stamp: 0x55763d32
Faulting module name: mscorwks.dll, version: 2.0.50727.5485, time stamp: 0x53a11d6c
Exception code: 0xc0000005
Fault offset: 0x0000000000501090
Faulting process id: 0x2960
Faulting application start time: 0x01d0c39a93c695f2
Faulting application path: C:\Program Files\Java\jre1.8.0_51\bin\javaw.exe
Faulting module path:C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
J'utilisais le kit EMET (Enhanced Mitigation Experience Toolkit) de Microsoft et je l'ai trouvé en désactivant les fonctionnalités EMET sur javaw.exe dans mon cas car il s'agissait de l'application défaillante, elle a permis à mon application de s'exécuter correctement. Assurez-vous de ne pas utiliser de logiciel similaire doté de protections de sécurité en mémoire.
Des problèmes avec les cadres de pile pourraient indiquer une corruption de pile (une bête vraiment horrible), une optimisation ou des structures de mixage telles que C/C++/C #/Delphi et autres folies semblables - il n’existe pas de norme absolue en ce qui concerne les cadres de pile . (Certaines langues ne les ont même pas!).
Je suggère donc de ne pas trop en vouloir, de ne pas en tenir compte, puis d’utiliser la réponse de Remy.