échec - windows server 2012 r2 service error 1053




Erreur 1053: le service n'a pas répondu à la demande de démarrage ou de contrôle en temps opportun (20)

J'ai récemment hérité de quelques applications qui s'exécutent en tant que services Windows, et j'ai des problèmes pour fournir un gui (accessible à partir d'un menu contextuel dans la barre d'état système) avec les deux.

La raison pour laquelle nous avons besoin d'un GUI pour un service Windows est de pouvoir reconfigurer le comportement du (des) service (s) Windows sans avoir recours à l'arrêt / au redémarrage.

Mon code fonctionne bien en mode débogage, et j'obtiens le menu contextuel, et tout se comporte correctement, etc.

Lorsque j'installe le service via "installutil" en utilisant un compte nommé (c'est-à-dire, pas de compte système local), le service fonctionne bien, mais n'affiche pas l'icône dans la barre d'état système (je sais que c'est un comportement normal avoir l'option "interagir avec le bureau").

Voici le problème: lorsque je choisis l'option "LocalSystemAccount" et que je coche l'option "interagir avec le bureau", le service prend AGES pour démarrer sans raison apparente, et je continue d'obtenir

Impossible de démarrer le service ... sur l'ordinateur local.

Erreur 1053: le service n'a pas répondu à la demande de démarrage ou de contrôle en temps opportun.

Incidemment, j'ai augmenté le délai d'expiration du service Windows de 30 secondes par défaut à 2 minutes via un hack de registre (voir http://support.microsoft.com/kb/824344 , recherche de TimeoutPeriod dans la section 3), mais le service démarre toujours Le temps est écoulé.

Ma première question est la suivante: pourquoi la connexion au compte "Système local" prend-elle SOOOOO BEAUCOUP PLUS longtemps que lorsque le service se connecte avec le non-LocalSystemAccount, provoquant l'expiration du délai de Windows? Quelle pourrait être la différence entre ces deux pour provoquer un comportement si différent au démarrage?

Deuxièmement, prendre un peu de recul, tout ce que j'essaie de faire, c'est simplement un service Windows qui fournit un gui pour la configuration - je serais très content d'utiliser le compte système non local (avec user / pwd), si je pouvais obtenir le service d'interagir avec le bureau (c'est-à-dire, avoir un menu contextuel disponible à partir de la barre d'état système). Est-ce possible, et si oui comment?

Toute indication sur les questions ci-dessus serait appréciée!


Je rencontrais un problème similaire avec un service que j'écrivais. Cela a bien fonctionné, puis un jour j'ai commencé à obtenir le délai d'attente sur les erreurs de démarrage. Cela s'est passé dans un et / ou à la fois Release et Debug en fonction de ce qui se passait. J'avais instancié un EventLogger de System.Diagnostics, mais quelle que soit l'erreur que je voyais, cela devait se produire avant que le Logger ne puisse écrire ...

Si vous ne savez pas où chercher les EventLogs, dans VS vous pouvez aller à votre machine sous l'Explorateur de Serveur. J'ai commencé à fouiner dans d'autres EventLogs en plus de ceux de mon service. Sous Application - .NETRuntime j'ai trouvé les journaux d'erreurs pertinents à l'erreur au démarrage. Fondamentalement, il y avait quelques exceptions dans le constructeur de mon service (un qui s'est avéré être une exception dans la configuration de l'instance EventLog - qui expliquait pourquoi je ne pouvais voir aucun journal dans mon Service EventLog). Sur une version précédente, apparemment, il y avait eu d'autres erreurs (ce qui m'avait amené à faire les changements conduisant à l'erreur dans la configuration d'EventLog).

Longue histoire courte - la raison du délai d'attente peut être due à diverses exceptions / erreurs, mais en utilisant le Runtime EventLogs peut vous aider à comprendre ce qui se passe (en particulier dans les cas où une construction fonctionne mais pas une autre).

J'espère que cela t'aides!


Installez la version de débogage du service et attachez le débogueur au service pour voir ce qui se passe.


Je veux faire écho aux commentaires de mdb ici. Ne va pas ce chemin. Votre service n'est pas censé avoir une interface utilisateur ... "Aucune interaction de l'utilisateur" est comme la caractéristique de définition d'un service.

Si vous devez configurer votre service, écrivez une autre application qui modifie la même configuration que celle que le service lit au démarrage. Mais en faire un outil distinct - lorsque vous voulez démarrer le service, vous démarrez le service. Lorsque vous voulez le configurer, vous exécutez l'outil de configuration.

Maintenant, si vous avez besoin d'une surveillance en temps réel du service, alors c'est un peu plus compliqué (et certainement quelque chose que j'ai souhaité avec les services). Maintenant, vous parlez d'avoir à utiliser les communications interprocessus et d'autres maux de tête.

Pire encore, si vous avez besoin de l'interaction de l'utilisateur, alors vous avez une vraie déconnexion, car les services n'interagissent pas avec l'utilisateur.

Dans vos chaussures, je voudrais prendre du recul et demander pourquoi cela doit-il être un service ? Et pourquoi a-t-il besoin d'une interaction de l'utilisateur ?

Ces deux exigences sont assez incompatibles, et cela devrait déclencher des alarmes.


Pour déboguer le démarrage de votre service, ajoutez ce qui suit au début de la méthode OnStart() de votre service:

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

Cela va bloquer le service jusqu'à ce que vous attachiez manuellement le débogueur Visual Studio à l'aide Debug -> Attach to Process ...

Remarque: En général, si vous avez besoin d'un utilisateur pour interagir avec votre service, il est préférable de diviser les composants de l'interface graphique en une application Windows distincte qui s'exécute lorsque l'utilisateur se connecte. Vous utilisez ensuite des canaux nommés ou une autre forme d'IPC établir la communication entre l'application graphique et votre service. C'est en fait le seul moyen de le faire dans Windows Vista.


Le compte système local et le service local ne fonctionnaient pas pour moi, puis je l'ai défini sur Service réseau et cela a fonctionné correctement.


Si vous continuez à essayer de faire interagir directement votre service avec le bureau de l'utilisateur, vous perdrez: même dans le meilleur des cas (c'est-à-dire «avant Vista»), c'est extrêmement compliqué.

Windows gère en interne plusieurs stations de fenêtre , chacune avec son propre bureau. La station de fenêtre affectée aux services s'exécutant sous un compte donné est complètement différente de la station de fenêtre de l'utilisateur interactif connecté. L'accès à la station cross-window a toujours été désapprouvé, car il existe un risque de sécurité, mais alors que les versions précédentes de Windows autorisaient quelques exceptions, elles ont été pratiquement éliminées dans Vista et les systèmes d'exploitation ultérieurs.

La raison la plus probable pour laquelle votre service est suspendu au démarrage est qu'il tente d'interagir avec un bureau inexistant (ou suppose que l'Explorateur s'exécute dans la session utilisateur système, ce qui n'est pas le cas) ou en attente d'un bureau invisible .

La seule solution fiable à ces problèmes consiste à éliminer tout le code de votre service et à le déplacer vers un exécutable distinct qui s'exécute dans la session utilisateur interactive (l'exécutable peut être démarré à l'aide du groupe Démarrage global, par exemple).

La communication entre votre code d'interface utilisateur et votre service peut être implémentée à l'aide de n'importe quel mécanisme RPC: Les tubes nommés fonctionnent particulièrement bien à cette fin. Si vos besoins en communications sont minimes, l'utilisation de commandes Service Control Manager définies par l' application peut également s'avérer utile.

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 fonctionner les choses de manière fiable, et vous servira bien dans le futur.

ADDENDUM, avril 2010: Comme cette question reste très populaire, voici un moyen de corriger un autre scénario commun qui provoque des erreurs "service n'a pas répondu ...", impliquant des services .NET qui n'essaient pas de choses amusantes comme interagir avec le bureau , mais utilisez des assemblys signés Authenticode: désactivez la vérification de la signature Authenticode au moment du chargement afin de créer une preuve Publisher en ajoutant les éléments suivants à votre fichier .exe.config:

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

La preuve de publication est une fonctionnalité CAS (Code Access Security) peu utilisée: uniquement dans l'éventualité peu probable où votre service s'appuierait sur PublisherMembershipCondition pour le désactiver. Dans tous les autres cas, les échecs de démarrage permanent ou intermittent disparaîtront, en n'exigeant plus que le moteur d'exécution effectue des vérifications coûteuses de certificats (y compris les recherches de liste de révocation).


Copiez la DLL de la version ou récupérez la DLL à partir du mode de publication plutôt que du mode Débogage et collez-la dans le dossier d'installation, cela devrait fonctionner


Après avoir combattu ce message pendant des jours, un ami m'a dit que vous DEVEZ utiliser la version Release. Lorsque je InstallUtil la construction Debug, il donne ce message. La version Release démarre correctement.


Dans la classe de service de la méthode OnStart, ne faites pas d'énorme opération, le système d'exploitation s'attend à un court laps de temps pour exécuter le service, exécutez votre méthode en utilisant le démarrage du thread:

protected override void OnStart(string[] args)
{
    Thread t = new Thead(new ThreadStart(MethodName)); // e.g.
    t.Start();
}

J'ai également fait face à un problème similaire et j'ai constaté qu'il y avait un problème de chargement. Je recevais cette erreur immédiatement lorsque j'essayais de démarrer le service.

Pour déboguer rapidement le problème, essayez d'exécuter le service exécutable via l'invite de commande à l'aide de ProcDump http://technet.microsoft.com/en-us/sysinternals/dd996900 . Il doit fournir une indication suffisante sur l'erreur exacte.

http://bytes.com/topic/net/answers/637227-1053-error-trying-start-my-net-windows-service m'a aidé un peu.


J'ai fait face à ce problème en raison d'un cadre manquant sur la boîte de mon service. La boîte avait .NET 4.0 et le service a été écrit au-dessus de .NET 4.5.

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


J'ai eu ce problème, il a fallu environ un jour pour réparer. Pour moi le problème était que mon code a sauté le "contenu principal" et couru effectivement quelques lignes alors fini. Et cela a causé l'erreur pour moi. Il s'agit d'une application de console C # qui installe un service Windows, dès qu'il a essayé de l'exécuter avec le ServiceController (sc.Run ()), alors il donnerait cette erreur pour moi.

Après avoir corrigé le code pour aller au contenu principal, il exécuterait le code prévu:

ServiceBase.Run(new ServiceHost());

Ensuite, il a cessé d'apparaître.

Comme beaucoup de gens l'ont déjà dit, l'erreur pourrait être n'importe quoi, et les solutions que les gens apportent peuvent ou ne peuvent pas le résoudre. S'ils ne le résolvent pas (comme le Release au lieu de Debug, en ajoutant generatePublisherEvidence = false dans votre config, etc), il y a de fortes chances que le problème soit avec votre propre code.

Essayez d'exécuter votre code sans utiliser sc.Run () (c'est-à-dire que le code soit exécuté par sc.Run ()).


Si vous utilisez le code de débogage comme ci-dessous dans votre service, le problème peut survenir.

#if(!DEBUG)
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[]
{
new EmailService()
};
ServiceBase.Run(ServicesToRun);
#else
//direct call function what you need to run
#endif

Pour résoudre ce problème, pendant que vous construisez votre service Windows, supprimez la condition #if car elle ne fonctionne pas comme elle est.

Veuillez utiliser l'argument pour le mode de débogage à la place comme ci-dessous.

if (args != null && args.Length > 0)
{
_isDebug = args[0].ToLower().Contains("debug");
}

Dans mon cas, le problème était la version manquante du .net framework .

Mon service utilisé

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

Mais .net Framework version .net Framework du serveur était 4, donc en changeant 4.5 à 4, le problème a été corrigé:

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>

Dans le cas où vous avez un formulaire Windows utilisé pour le test, assurez-vous que l'objet de démarrage est toujours le service et non le formulaire Windows


Log4Net est configuré pour se connecter à une table de base de données. La table était devenue si grande que le service expirait en essayant de consigner les messages.


  1. Construire un projet en mode Release.
  2. Copiez tous les fichiers du dossier Release vers le chemin source.
  3. Exécute le service Window à l'aide de la fenêtre d'invite de commande dans l'accès administratif.
  4. Ne jamais supprimer les fichiers du chemin source.

Au bail cela fonctionne pour moi.


Une fois, essayez d'exécuter votre fichier exe. J'ai eu le même problème, mais quand je l'ai couru directement en double-cliquant sur le fichier exe, j'ai reçu un message sur la version du framework .Net, car j'ai été libéré le projet avec un framework qui n'était pas installé sur la machine cible.


Ça m'a pris des heures, j'aurais dû voir l'event viewer get_AppSettings () .

Une modification de la configuration de l'application a provoqué le problème.


Mon problème était dû au cadre cible mentionné dans la configuration du service Windows était

<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
 </startup>

et mon serveur dans lequel j'ai essayé d'installer le service Windows n'a pas été pris en charge pour cette version .Net.

Changer ce qui, je pourrais capable de résoudre le problème.





timeout