web-dev-qa-db-fra.com

Pourquoi l'échec de StartServiceCtrlDispatcher () avec 1063 (ERROR_FAILED_SERVICE_CONTROLLER_CONNECT)?

Je vois une erreur étrange avec mon programme de service Windows. Mon programme de service appelle StartServiceCtrlDispatcher() au tout début de sa main(), mais il échoue parfois avec 1063 (ERROR_FAILED_SERVICE_CONTROLLER_CONNECT).

Je sais que cette erreur se produit si l'utilisateur démarre le programme manuellement (en tant que programme console). Mais ce n'est pas le cas. J'ai ajouté un code pour vérifier le processus parent du programme de service lorsque cette erreur se produit. Il indique que services.exe est le processus parent (je pense qu'il est prudent de supposer que mon programme a été démarré correctement par SCM).

Malheureusement, cette erreur ne se reproduit pas sur ma machine dev et ne peut pas la déboguer par moi-même, mais les journaux d'erreurs capturés sur les systèmes utilisateur indiquent:

  • Ce problème semble ne se produire que sur quelques% des utilisateurs de ce programme.
  • Même si le problème se produit, il ne semble pas se répéter. La prochaine fois que le service démarre généralement avec succès.
  • Lorsque ce problème se produit, StartServiceCtrlDispatcher() reste bloqué environ une seconde avant qu'il ne revienne avec échec.

Quelqu'un at-il vu une erreur similaire? Si oui, quelle était la cause de l'erreur?

11
Susumu Arai

Comme vous pouvez déjà le constater par l’absence de réponses et de données sur Google, le problème n’est pas commun. Je crois que le problème se situe dans votre service ET qu'il concerne le code exécuté depuis le début du processus vers StartServiceCtrlDispatcher(), ET il est très probable qu'il prenne une forme de corruption des ressources système, vraisemblablement du tas ou des HANDLEname__.

Vous pouvez être désolé d'entendre cela, mais je ne vais pas avoir une réponse magique à vos problèmes. Au lieu de cela, je peux suggérer un dépannage.

Microsoft Application Verifier est un outil précieux pour détecter la corruption. Je vous suggère:

  1. Installez-le sur votre machine dev.
  2. Ajoutez l'exe de votre service.
  3. Ne sélectionnez Basics\Heaps que pour la première fois.
  4. Appuyez sur Enregistrer. Peu importe si vous maintenez le vérificateur d'applications ouvert.
  5. Exécutez votre service plusieurs fois.
  6. S'il se bloque, corrigez-le et le crash indiquera votre problème.
  7. S'il ne se bloque pas, ajoutez Basics\Handles. Contrairement à Basics\Heaps, cela peut parfois déclencher des "faux positifs" - des erreurs de code qui ne font pas trop mal. Quoi qu'il en soit, puisque vous êtes à la chasse, vous feriez mieux de réparer tout ce que vous pouvez trouver. Je m'inquiète surtout de la double libération d'un HANDLEou de quelque chose du genre. La libération par erreur d'un gestionnaire de services HANDLEpeut certainement conduire à votre problème.
  8. Si cela ne plante toujours pas, vous pouvez essayer d'autres options dans Basics\*, mais je ne pense pas que cela vous aidera.
  9. À ce stade, vous voudrez peut-être inspecter le code entre les fonctions main() et StartServiceCtrlDispatcher() du programme et tous les constructeurs globaux que vous pouvez avoir. Recherchez les éventuels débordements de mémoire tampon et les erreurs avec HANDLEname __ 's.
  10. L'étape suivante pourrait être l'installation d'Application Verifier sur la machine du client. Il n'y a pas beaucoup de mal à cela, je le fais parfois quand je ne trouve pas l'erreur moi-même.
7
Codeguard

CONSEIL: j’ai utilisé _wfopen/fwrite/fclose pour enregistrer certains messages. D'une manière ou d'une autre, 183 a été lancé en interne et entraînait cet échec 1063. J'ai supprimé la journalisation et cela a commencé à fonctionner normalement car rien ne s'est passé. Toute erreur minute peut vous y conduire. Commencez par les services et il listera l'erreur de salaire (183 dans mon cas).

0
hidalgo