détecter la fin du programme (C, Windows)

1. Win32

L’API Win32 contient un moyen de le faire via la fonction SetUnhandledExceptionFilter , comme suit:

LONG myFunc(LPEXCEPTION_POINTERS p) { printf("Exception!!!\n"); return EXCEPTION_EXECUTE_HANDLER; } int main() { SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)&myFunc); // generate an exception ! int x = 0; int y = 1/x; return 0; } 

2. POSIX / Linux

Je le fais généralement via la fonction signal () , puis gère le signal SIGSEGV de manière appropriée. Vous pouvez également gérer le signal SIGTERM et SIGINT, mais pas SIGKILL (de par leur conception). Vous pouvez utiliser strace () pour obtenir une trace pour voir ce qui a causé le signal.

Il existe des threads de forum sysinternals sur la protection contre les tentatives de fin de processus en accrochant NT Internals, mais ce que vous voulez vraiment, c’est un processus watchdog ou peer (approche raisonnable) ou une méthode d’interception des événements catastrophiques.

Edit: Il y a des raisons pour lesquelles cela rend les choses difficiles, mais il est possible d’intercepter ou de bloquer les tentatives de tuer votre processus. Je sais que vous essayez juste de nettoyer avant de quitter, mais dès que quelqu’un libère un processus qui ne peut pas être tué immédiatement, quelqu’un demandera une méthode pour le tuer immédiatement, et ainsi de suite. Quoi qu’il en soit, pour suivre cette voie, consultez le fil de discussion ci-dessus et recherchez des mots-clés que vous y trouverez pour en savoir plus. hook or filter NtTerminateProcess, etc. Certains ouvrages à aider dans ce domaine sont l’ API native Windows NT / 2000 , les secrets Windows 2000 non documentés: le livre de recettes d’un programmeur , les rootkits: subversion du kernel Windows et, bien sûr, les composants internes Windows®: cinquième édition . Ce genre de chose n’est pas trop difficile à coder, mais plutôt délicat pour être juste, et vous pouvez introduire des effets secondaires inattendus.

Peut-être que les fonctions de récupération d’application et de redémarrage pourraient être utiles? Pris en charge par Vista et Server 2008 et versions ultérieures.

ApplicationRecoveryCallback Callback Function Fonction de rappel définie par l’application utilisée pour enregistrer des données et des informations sur l’état de l’application au cas où l’application rencontre une exception non gérée ou ne répond plus.

En utilisant SetUnhandledExceptionFilter , la discussion MSDN Social conseille que pour que cela fonctionne correctement , appliquer cette méthode en mémoire est la seule façon de s’assurer que votre filtre est appelé. Conseille plutôt de boucler avec __try / __ sauf. Quoi qu’il en soit, il existe un exemple de code et de discussion sur les appels de filtrage à SetUnhandledExceptionFilter dans l’article “SetUnhandledExceptionFilter” et VC8 .

En outre, voir Windows SEH Revisited à The Awesome Factor pour un exemple de code de AddVectoredExceptionHandler .

Cela dépend de ce que vous faites avec vos “exceptions”. Si vous les manipulez correctement et quittez le programme, vous pouvez enregistrer votre fonction à appeler en utilisant atexit() .

Cela ne fonctionnera pas en cas de terminaison anormale réelle, comme par exemple une erreur de segmentation.

Vous ne savez pas à propos de Windows, mais sur un système d’exploitation compatible POSIX, vous pouvez installer un gestionnaire de signal qui détecte différents signaux et y réagit. Bien sûr, vous ne pouvez pas attraper SIGKILL et SIGSTOP .

Signal API fait partie d’ANSI C depuis C89, probablement Windows le supporte. Voir syscall signal() pour plus de détails.

Si ce n’est que Windows, vous pouvez utiliser SEH ( SetUnhandledExceptionFilter ) ou VEH ( AddVectoredExceptionHandler , mais uniquement pour XP / 2003 et les versions ultérieures).

Désolé, pas un programmeur Windows. Mais peut-être

 _onexit() 

Enregistre une fonction à appeler lorsque le programme se termine.

http://msdn.microsoft.com/en-us/library/aa298513%28VS.60%29.aspx

Tout d’abord, bien que cela soit assez évident: vous ne pouvez jamais avoir une solution complètement robuste – quelqu’un peut toujours appuyer sur le câble d’alimentation pour mettre fin à votre processus. Il vous faut donc un compromis et vous devez définir avec soin les détails de ce compromis.

L’une des solutions les plus robustes consiste à placer le code approprié dans un programme d’encapsulation. Le programme wrapper appelle votre “vrai” programme, attend que son processus se termine, puis – à moins que votre “vrai” programme ne signale spécifiquement qu’il s’est terminé normalement – exécute le code de nettoyage. Ceci est assez commun pour des choses comme les harnais de test, où le programme de test est susceptible de tomber en panne ou d’abandonner ou de mourir de manière inattendue.

Cela vous donne toujours la difficulté de savoir ce qui se passe si quelqu’un exécute un TerminateProcess sur votre fonction wrapper, si cela doit vous préoccuper. Si nécessaire, vous pouvez contourner ce problème en le configurant en tant que service dans Windows et en utilisant les fonctionnalités du système d’exploitation pour le redémarrer s’il meurt. (Cela change un peu les choses; quelqu’un pourrait encore arrêter le service). À ce stade, vous êtes probablement au sharepoint devoir terminer le test par quelque chose de persistant, comme la création d’un fichier.

J’ai publié un article sur ddj.com sur “le débogage post mortem” il y a quelques années.

Il comprend des sources pour Windows et Unix / Linux pour détecter les terminaisons anormales. D’après mon expérience, un gestionnaire Windows installé à l’aide de SetUnhandledExceptionFilter n’est pas toujours appelé. Dans de nombreux cas, il est appelé, mais je reçois un certain nombre de fichiers journaux des clients qui n’incluent pas de rapport des gestionnaires installés, d’où la cause d’une VIOLATION D’ACCES.

http://www.ddj.com/development-tools/185300443