Erreur 1053: le service n'a pas répondu à la demande de démarrage ou de contrôle dans les délais

Question

je sais que c'est très bien un "quelle est la durée d'un morceau de ficelle" type de question, cependant, j'ai récemment hérité d'un couple d'applications qui s'exécutent en tant que services windows, et je vais avoir des problèmes en fournissant une interface graphique (accessible à partir d'un menu contextuel dans la barre d'état système) avec deux d'entre eux.

avant de vous demander, la raison pour laquelle nous avons besoin d'une interface graphique pour un service windows est en ordre pour être en mesure de re-configurer le comportement de la windows service(s) sans recourir à l'arrêt/remise en marche.

mon code fonctionne très bien en mode debug, et j'obtiens le menu contextuel, et tout fonctionne correctement etc.

quand j'ai installer le service par l'intermédiaire de "installutil" à l'aide d'un compte nommé (c'est à dire, pas de Compte Système Local), le service fonctionne très bien, mais n'affiche pas l'icône dans la barre d'état système (je sais que ce comportement est normal car je n'ai pas le "interagir avec le bureau" en option).

ici, est le problème - quand j'ai choisi le "LocalSystemAccount option", et cocher la case "interagir avec le bureau" option, le service prend une éternité à démarrer sans raison apparente, et je reçois des "impossible de démarrer le ... service sur l'Ordinateur Local. Erreur 1053: le service n'a pas répondu à la demande de lancement ou de contrôle en temps voulu".

d'ailleurs, j'ai augmenté le service windows délai d'expiration par défaut de 30 secondes à 2 minutes par l'intermédiaire d'un registre hack (voir http://support.microsoft.com/kb/824344, recherche pour TimeoutPeriod dans la section 3), cependant, le service de démarrage toujours du temps.

ma première question est: - pourquoi le "Compte Système Local" login prend SOOOOO BEAUCOUP PLUS de temps que lorsque le service se connecte avec le non-LocalSystemAccount, provoquant le service windows time-out? ce qui pourrait le faire la différence entre ces deux causer de telles différences de comportement au démarrage?

deuxièmement, en prenant un pas en arrière, tout ce que je suis en train de réaliser, c'est tout simplement un service windows qui fournit une interface graphique pour la configuration, je serais très heureux de courir à l'aide de la non-Compte Système Local (avec named user/pwd), si je pouvais obtenir le service à interagir avec le bureau (qui est, avoir un menu contextuel accessible à partir de la barre d'état système). est-ce possible, et si oui, comment?

les pointeurs vers les questions ci-dessus serait très apprécié!

merci d'avance pour votre aide.

Answer 1

Après avoir combattu ce message pendant des jours, un ami m'a dit que vous DEVEZ utiliser la version Release. Lorsque j'installe la version de débogage, il donne ce message. La version Release commence bien.

Answer 2

Si vous continuez sur la route en essayant de rendre votre service à interagir avec le bureau de l'utilisateur directement, vous allez perdre: même dans le meilleur des cas (c'est à dire "avant de Vista"), ce qui est extrêmement difficile.

Windows gère plusieurs stations de fenêtre, chacun avec leur propre ordinateur de bureau. La fenêtre de station attribué aux services s'exécutant dans le cadre d'un compte est totalement différente de la fenêtre de la station de la session interactive de l'utilisateur. La croix-fenêtre d'accès aux stations a toujours été mal vu, c'est un risque pour la sécurité, mais alors que les précédentes versions de Windows a permis à certaines exceptions près, ceux-ci ont été en grande partie éliminé dans Vista et les systèmes d'exploitation ultérieurs.

La raison la plus probable de votre service est suspendu au démarrage, c'est parce qu'il essaie d'interagir avec un inexistant bureau (ou suppose Explorer est en cours d'exécution à l'intérieur du système de session de l'utilisateur, qui n'est pas le cas), ou en attente d'entrée à partir d'un invisible bureau.

La seule fiable correctif pour ces problèmes est d'éliminer tous les code de l'INTERFACE utilisateur de votre service, et de le déplacer vers un autre exécutable qui s'exécute à l'intérieur de la session utilisateur interactive (l'exécutable peut être démarré à l'aide de la mondiale groupe de Démarrage, par exemple).

La Communication entre votre code de l'INTERFACE utilisateur et de votre service peut être mis en œuvre à l'aide de tout mécanisme RPC: des canaux fonctionnent particulièrement bien à cette fin. Si vos besoins en matière de communications sont minimes, à l'aide de l'application définie par le Service Gestionnaire de Contrôle des commandes peut également faire l'affaire.

Il faudra un certain effort pour réaliser cette séparation entre l'INTERFACE utilisateur et le code de service: cependant, c'est la seule façon de faire les choses fonctionnent de manière fiable, et vous sera utile dans l'avenir.

ADDENDUM, avril 2010: Depuis que cette question reste assez populaire, voici un moyen de fixer un autre scénario qui provoque "le service n'a pas répondu..." erreurs, impliquant .NET services qui n'essaiera pas de trucs drôles comme l'interaction avec le bureau, mais n' utilisez signature Authenticode assemblées: désactiver la vérification de la signature Authenticode au moment du chargement dans le but de créer de l'Éditeur de preuve, en ajoutant les éléments suivants à votre .exe.fichier de configuration:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

L'éditeur de la preuve est un peu utilisée Sécurité d'Accès du Code (CAS) fonction: seulement dans le cas peu probable que votre service effectivement s'appuie sur la PublisherMembershipCondition va désactiver causer des problèmes. Dans tous les autres cas, il fera le permanent ou intermittent d'échec de démarrage de s'en aller, en n'exigeant plus que le moteur d'exécution à faire cher le certificat de contrôle (y compris la liste de révocation de recherches).

Answer 3

J'ai rencontré ce problème à cause d'un cadre manquant sur la boîte d'exécution de mon service. La boîte avait .NET 4.0 et le service était écrit sur .NET 4.5.

J'ai installé le téléchargement suivant sur la boîte, puis redémarré et le service a démarré correctement: http://www.microsoft.com/en-us/download/details.aspx?id=30653

Answer 4

Pour déboguer le démarrage de votre service, ajoutez le code suivant en haut de l' OnStart() méthode de votre service:

 while(!System.Diagnostics.Debugger.IsAttached) Thread.Sleep(100);

Cela permettra de caler le service jusqu'à ce que vous manuellement attacher le Débogueur de Visual Studio à l'aide de Débogage -> Attach to Process...

Remarque: En général, si vous avez besoin d'un utilisateur d'interagir avec votre service, il est préférable de diviser composants de l'interface utilisateur dans une autre application Windows qui s'exécute lorsque l'utilisateur se connecte. Ensuite, vous utilisez quelque chose comme des canaux nommés ou l'autre forme de l'IPC pour établir la communication entre l'interface de l'app et de votre service. C'est en fait la seule façon que cela est possible dans Windows Vista.

Answer 5

Je suis prise de vue à l'aveugle ici, mais j'ai très souvent constaté que de longs retards dans le service de startups sont causées directement ou indirectement par la fonction de réseau les délais d'attente, souvent, quand attemting contacter un contrôleur de domaine lors de la recherche de compte Sid - ce qui arrive très souvent indirectement par l'intermédiaire d' GetMachineAccountSid() que vous le réalisiez ou non, étant donné que la fonction est appelée par le sous-système RPC.

Pour un exemple sur la façon de déboguer dans de telles situations, voir Le Cas du Processus de Démarrage de Retards sur Mark Russinovich blog.