Les Services Windows de Récupération de ne pas redémarrer le service

- Je configurer la récupération pour les services Windows pour redémarrer avec un délai d'une minute après les échecs. Mais je n'ai jamais eu à le faire en fait redémarrer le service (même avec les plus flagrantes erreurs).

Je reçois un message dans l'EventViewer:

La description pour l'ID d'Événement ( 1 ) dans la Source ( MyApp.exe ) ne peut pas être trouvé. L'ordinateur local ne dispose pas de l'information nécessaire de registre ou les fichiers DLL de message pour afficher les messages à partir d'un ordinateur distant. Vous pouvez être en mesure d'utiliser le /AUXSOURCE= indicateur pour récupérer cette description; voir Aide et Support pour plus de détails. Les informations suivantes font partie de l'événement: violation d'Accès à l'adresse 00429874 dans le module 'MyApp.exe'. Écriture de l'adresse 00456704.

Est-il autre chose que je dois faire? Est-il quelque chose dans mon code (j'utilise Delphi) qui doit être établi pour permettre cela?

InformationsquelleAutor M Schenkel | 2009-11-19
  1. 20

    La Reprise du Service est prévu pour gérer le cas où un service tombe en panne, donc si vous allez à taskmgr et à droite cliquez sur "terminer le processus" dans votre processus de service, la récupération de la logique devrait coup de pied dans. Je ne crois pas que le service de la logique de récupération des coups de pied dans si votre service des sorties gracieusement (même si il sort avec une erreur).

    Également la eventvwr message indique que votre application appelée ReportEvent API spécifiant l'ID d'événement 1. Mais vous n'avez pas enregistré vos messages d'événement avec l'observateur d'événements, de sorte qu'il ne peut pas convertir l'ID d'événement 1 dans une véritable chaîne de texte.

    • Merci. Ce jeter quelque lumière sur la situation. J'ai trouvé quand j'ai fait un "terminer le Processus" du gestionnaire de tâches de production de la présente dans l'observateur d'événements: L'action corrective suivante va être effectuée dans 60 000 millisecondes: Redémarrer le service. Maintenant mon problème (qui est liée à mon coding) est de l'avoir terminiate "de l'Onu-Gracieusement", de sorte que la logique de récupération donnera un coup de pied dans.
    • Si vous appelez ExitProcess qui devrait être suffisante.
    InformationsquelleAutor Larry Osterman
  2. 9

    Service de Récupération ne fonctionne que pour une fermeture inattendue comme (exit(-1)) appel.
    Pour tout le chemin que nous utilisons pour arrêter le service de manière habituelle ne fonctionne pour la récupération.
    Si vous voulez arrêter de service et veut toujours récupération, appel exit(-1) et vous verrez message d'erreur comme "le service s'est arrêté avec l'erreur inattendue" , puis votre redémarrage du service en tant que paramètre de récupération est.

    • +1 Merci pour votre réponse. M'a beaucoup aidé
    • Pour ceux qui recherchent la méthode exacte, essayez de l'Environnement.Exit(-1);
    InformationsquelleAutor suprit chaudhary
  3. 3

    Le Gestionnaire de Contrôle de Service va tenter de redémarrer votre service si vous avez configuré pour être redémarré par le SCM. Ceci est détaillé ici dans la documentation de l' SERVICE_FAILURE_ACTIONS structure.

    Un service est considéré comme ayant échoué quand il
    se termine sans la déclaration d'un état de SERVICE_STOPPED à l'
    contrôleur de service.

    Cela peut être réglé par le paramètre de la SERVICE_FAILURE_ACTIONS_FLAG de la structure fFailureActionsOnNonCrashFailures indicateur, voir la ici). Vous pouvez définir ce paramètre à partir de l'applet Services en cochant l'option "Activer les actions pour les arrêts avec des erreurs" case à cocher dans l'onglet récupération.

    Si ce membre est VRAI, et le service a configuré l'échec des actions, l'échec des actions sont mises en file d'attente si le service processus se termine sans que la déclaration d'un état de SERVICE_STOPPED ou si elle entre dans le SERVICE_STOPPED l'etat, mais le dwWin32ExitCode membre de la SERVICE_STATUS structure n'est pas ERROR_SUCCESS (0).
    Si ce membre est FAUX, et le service a configuré l'échec des actions, l'échec des actions sont mises en file d'attente que si le service se termine sans que la déclaration d'un état de SERVICE_STOPPED.

    Ainsi, selon la façon dont vous avez structuré votre service, comment vous avez configuré votre échec actes ET ce que vous faites quand vous avez votre "erreur fatale", il peut être suffisant pour appeler ExitProcess() ou exit() et retourner d'un pas égal à zéro. Cependant, il est probablement plus sûr de vous assurer que votre service quitte sans le code qui interagit avec le SCM dire la SCM que votre service a atteint le SERVICE_STOPPED état. Cela garantit que votre échec des actions de TOUJOURS arriver...

    InformationsquelleAutor Len Holgate
  4. 0

    Si vous "tuer" le service partir du gestionnaire de tâches - oublié pour la logique de récupération. En arrière-plan le gestionnaire des tâches 'tue' processus 'stop service". et comme vous pouvez le deviner, ce n'est pas l'échec du service. Cela m'a forcé à le tuer vraiment avec Visual Studio. Dans le gestionnaire des tâches clic droit sur le processus de service. Sélectionnez déboguer.
    Dans Visual studio, sélectionnez Debug-> mettre fin à Tous.
    Et maintenant, vous avez simulé service de l'échec. Dans ce cas, la logique de récupération fonctionne très bien.

    InformationsquelleAutor Kostadin