windows - tiempo - Error 1053: el servicio no respondió a la solicitud de inicio o control de manera oportuna
error 1053 windows server 2012 r2 (29)
Me enfrenté a este problema debido a la falta de un marco en la caja que ejecuta mi servicio. La caja tenía .NET 4.0 y el servicio estaba escrito encima de .NET 4.5.
Instalé la siguiente descarga en la caja, reinicié mi funcionamiento y el servicio se inició correctamente: http://www.microsoft.com/en-us/download/details.aspx?id=30653
Recientemente he heredado un par de aplicaciones que se ejecutan como servicios de Windows, y tengo problemas para proporcionar una interfaz gráfica (accesible desde un menú contextual en la bandeja del sistema) con ambas.
La razón por la cual necesitamos una interfaz gráfica para un servicio de Windows es para poder reconfigurar el comportamiento de los servicios de Windows sin recurrir a detener / reiniciar.
Mi código funciona bien en el modo de depuración, y aparece el menú contextual, y todo se comporta correctamente, etc.
Cuando instalo el servicio a través de "installutil" usando una cuenta nombrada (es decir, no cuenta del sistema local), el servicio funciona bien, pero no muestra el ícono en la bandeja del sistema (sé que esto es un comportamiento normal porque no lo hago). tener la opción "interactuar con el escritorio").
Sin embargo, este es el problema: cuando elijo la opción "LocalSystemAccount" y marque la opción "interactuar con el escritorio", el servicio requiere AGES para iniciarse sin ninguna razón obvia, y sigo recibiendo
No se pudo iniciar el ... servicio en la computadora local.
Error 1053: el servicio no respondió a la solicitud de inicio o control de manera oportuna.
A propósito, aumenté el tiempo de espera del servicio de Windows de 30 segundos a 2 minutos predeterminados a través de un hack de registro (vea http://support.microsoft.com/kb/824344 , busque TimeoutPeriod en la sección 3), sin embargo, el servicio aún se inicia se acabó el tiempo.
Mi primera pregunta es: ¿por qué el inicio de sesión de la "Cuenta del sistema local" lleva MUCHO MUCHO MÁS TIEMPO que cuando el servicio inicia sesión con la cuenta LocalSystemAccount, causando el tiempo de espera del servicio de Windows? ¿Cuál podría ser la diferencia entre estos dos para causar un comportamiento tan diferente al inicio?
En segundo lugar, dar un paso atrás, todo lo que intento lograr es simplemente un servicio de Windows que proporciona una guía para la configuración. Sería un placer para mí correr usando la Cuenta de sistema no local (con usuario nombrado / pwd), si pudiera hacer que el servicio interactúe con el escritorio (es decir, tener un menú contextual disponible en la bandeja del sistema). ¿Es posible? y si lo es, cómo?
¡Cualquier sugerencia a las preguntas anteriores sería apreciada!
Estoy disparando a ciegas, pero a menudo encuentro que los retrasos en el inicio del servicio son causados directa o indirectamente por tiempos de espera de la función de red, a menudo cuando intento contactar un controlador de dominio cuando busco los SID de la cuenta, lo que sucede muy a menudo indirectamente GetMachineAccountSid() ya sea que se dé cuenta o no, ya que el subsistema RPC llama a esa función.
Para ver un ejemplo sobre cómo depurar en tales situaciones, consulte El caso de las demoras de inicio del proceso en el blog de Mark Russinovich.
Instale la compilación de depuración del servicio y adjunte el depurador al servicio para ver qué está sucediendo.
Para depurar el inicio de su servicio, agregue lo siguiente a la parte superior del método OnStart() de su servicio:
while(!System.Diagnostics.Debugger.IsAttached) Thread.Sleep(100);
Esto detendrá el servicio hasta que conecte manualmente el depurador de Visual Studio mediante Debug -> Adjuntar para procesar ...
Nota: en general, si necesita que un usuario interactúe con su servicio, es mejor dividir los componentes de la GUI en una aplicación de Windows separada que se ejecute cuando el usuario inicie sesión. A continuación, utilice algo como named pipes o alguna otra forma de IPC. para establecer comunicación entre la aplicación GUI y su servicio. De hecho, esta es la única forma en que esto es posible en Windows Vista.
Quiero hacerme eco de los comentarios de mdb aquí. No vayas por este camino. Se supone que su servicio no tiene una UI ... "Sin interacción del usuario" es como la característica de definición de un servicio.
Si necesita configurar su servicio, escriba otra aplicación que edite la misma configuración que el servicio lee al inicio. Pero conviértalo en una herramienta distinta: cuando desea comenzar el servicio, comienza el servicio. Cuando quiere configurarlo, ejecuta la herramienta de configuración.
Ahora, si necesita una supervisión en tiempo real del servicio, eso es un poco más complicado (y ciertamente algo que he deseado con los servicios). Ahora estás hablando de tener que usar comunicaciones entre procesos y otros dolores de cabeza.
Lo peor de todo es que si necesita la interacción del usuario, entonces tiene una desconexión real aquí, porque los servicios no interactúan con el usuario.
En sus zapatos, daría un paso atrás y preguntaría por qué necesita ser un servicio . ¿ Y por qué necesita la interacción del usuario ?
Estos dos requisitos son bastante incompatibles, y eso debería generar alarmas.
También tuve este problema. Lo hice funcionar cambiando la cuenta de inicio de sesión a la cuenta del sistema local. En mi proyecto, lo configuré para que se ejecutara como cuenta de servicio local. Entonces, cuando lo instalé, de manera predeterminada estaba usando el servicio local. Estoy usando .net 2.0 y VS 2005. Así que instalar .net 1.1 SP1 no me hubiera ayudado.
Tanto la cuenta del sistema local como el servicio local no funcionarían para mí, luego lo configuré para el servicio de red y funcionó bien.
Si continúa por el camino de tratar de hacer que su servicio interactúe directamente con el escritorio del usuario, perderá: incluso en las mejores circunstancias (es decir, "antes de Vista"), esto es extremadamente complicado.
Windows administra internamente varias estaciones de ventana , cada una con su propio escritorio. La estación de ventana asignada a los servicios que se ejecutan bajo una cuenta dada es completamente diferente de la estación de ventana del usuario interactivo conectado. El acceso a estaciones de ventanas cruzadas siempre ha sido mal visto, ya que es un riesgo de seguridad, pero mientras que las versiones anteriores de Windows permitían algunas excepciones, estas se han eliminado principalmente en Vista y sistemas operativos posteriores.
La razón más probable por la que su servicio se cuelga al inicio es porque está tratando de interactuar con un escritorio inexistente (o asume que Explorer se está ejecutando dentro de la sesión del usuario del sistema, que tampoco es el caso), o esperando la entrada desde un escritorio invisible .
La única solución confiable para estos problemas es eliminar todo el código de UI de su servicio y moverlo a un ejecutable independiente que se ejecuta dentro de la sesión de usuario interactivo (el ejecutable se puede iniciar utilizando el grupo de inicio global, por ejemplo).
La comunicación entre su código de IU y su servicio se puede implementar utilizando cualquier mecanismo de RPC: las tuberías con nombre funcionan especialmente bien para este propósito. Si sus necesidades de comunicación son mínimas, el uso de comandos del Administrador de control de servicios definidos por la aplicación también puede ser útil.
Se requerirá un cierto esfuerzo para lograr esta separación entre la IU y el código de servicio: sin embargo, es la única manera de hacer que las cosas funcionen de manera confiable, y le servirá bien en el futuro.
ADDENDUM, abril de 2010: dado que esta pregunta sigue siendo muy popular, aquí hay una forma de corregir otro escenario común que causa errores del "servicio no respondido ...", que involucran servicios .NET que no intentan nada divertido como interactuar con el escritorio , pero sí utiliza ensamblajes firmados con Authenticode: deshabilite la verificación de la firma de Authenticode en el momento de la carga para crear evidencia del publicador , agregando los siguientes elementos a su archivo .exe.config:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
La evidencia del editor es una característica de seguridad de acceso de código (CAS, por sus siglas en inglés) poco utilizada: solo en el caso poco probable de que su servicio dependa realmente de PublisherMembershipCondition, la deshabilitará y causará problemas. En todos los demás casos, las fallas de inicio permanentes o intermitentes desaparecerán, al no requerir más el tiempo de ejecución para realizar costosas comprobaciones de certificados (incluidas las búsquedas de listas de revocación).
En mi caso, tuve este problema debido a un error genuino. Antes de llamar al constructor del servicio, un constructor estático de la variable miembro estaba fallando:
private static OracleCommand cmd;
static SchedTasks()
{
try
{
cmd = new OracleCommand("select * from change_notification");
}
catch (Exception e)
{
Log(e.Message);
// "The provider is not compatible with the version of Oracle client"
}
}
Al agregar el bloque try-catch, encontré que la excepción ocurría debido a una versión incorrecta de Oracle. La instalación de la base de datos correcta resolvió el problema.
Copie el archivo DLL de lanzamiento o obtenga el dll del modo de lanzamiento en lugar del modo de depuración y péguelo en la carpeta de instalación, debería funcionar
Después de luchar contra este mensaje durante días, un amigo me dijo que DEBES usar la compilación Release. Cuando instaloUtilice la compilación de depuración, este mensaje aparece. La versión de lanzamiento comienza bien.
Tuve este problema y me volvió loco durante dos días ... Si su problema es similar al mío:
Tengo la configuración "Configuración de usuario" en mi servicio de Windows, por lo que el servicio puede realizar un mantenimiento automático, sin detenerse e iniciar el servicio. Bueno, el problema es con la "configuración de usuario", donde el archivo de configuración para esta configuración se guarda en una carpeta bajo el perfil de usuario del usuario que ejecuta el servicio de Windows en la versión del archivo service-exe.
Esta carpeta, por alguna razón, estaba dañada. Eliminé la carpeta y el servicio comenzó a funcionar nuevamente felizmente como de costumbre ...
En la clase de servicio dentro del método OnStart, no haga una operación enorme, el sistema operativo espera una cantidad de tiempo breve para ejecutar el servicio, ejecute su método usando el inicio de proceso:
protected override void OnStart(string[] args)
{
Thread t = new Thead(new ThreadStart(MethodName)); // e.g.
t.Start();
}
También me enfrenté a un problema similar y descubrí que había un problema al cargar el ensamblaje. Recibí este error de inmediato al intentar iniciar el servicio.
Para solucionar el problema rápidamente, intente ejecutar el ejecutable del servicio mediante el símbolo del sistema utilizando ProcDump http://technet.microsoft.com/en-us/sysinternals/dd996900 . Proporcionará una pista suficiente sobre el error exacto.
http://bytes.com/topic/net/answers/637227-1053-error-trying-start-my-net-windows-service me ayudó bastante.
Agregar 127.0.0.1 crl.microsoft.com al archivo "Hosts" resolvió nuestro problema.
Me encontré con un problema similar con un servicio que estaba escribiendo. Funcionó bien, entonces un día comencé a obtener el tiempo de espera en los errores de Inicio. Ocurrió en uno y / o en ambos, Release y Debug, dependiendo de lo que estaba pasando. Instalé un EventLogger de System.Diagnostics, pero el error que estaba viendo debe haber sucedido antes de que el Logger pudiera escribir ...
Si no sabe dónde buscar los EventLogs, en VS puede ir a su máquina en Server Explorer. Empecé a hurgar en algunos de los otros EventLogs además de los de mi Servicio. En Aplicación - .NETRuntime encontré los registros de errores pertinentes al error al inicio. Básicamente, había algunas excepciones en el constructor de mi servicio (una resultó ser una excepción en la configuración de la instancia de EventLog, lo que explicaba por qué no podía ver ningún registro en mi Service EventLog). En una compilación anterior aparentemente había habido otros errores (que me habían llevado a realizar los cambios que conducen al error en la configuración de EventLog).
Para resumir, la razón del tiempo de espera puede deberse a varias excepciones / errores, pero usar Runtime EventLogs puede ayudarlo a descubrir qué está sucediendo (especialmente en las instancias donde una construcción funciona pero otra no).
¡Espero que esto ayude!
Tuve este problema, tomó alrededor de un día arreglarlo. Para mí, el problema fue que mi código omitió el "contenido principal" y efectivamente ejecutó un par de líneas y luego finalizó. Y esto causó el error para mí. Es una aplicación de consola C # que instala un servicio de Windows, tan pronto como intentó ejecutarlo con ServiceController (sc.Run ()), entonces me daría este error.
Después de arreglar el código para ir al contenido principal, se ejecutará el código previsto:
ServiceBase.Run(new ServiceHost());
Luego dejó de aparecer.
Como mucha gente ya ha dicho, el error podría ser cualquier cosa, y las soluciones que las personas proporcionan pueden o no resolverlo. Si no lo resuelven (como Release en lugar de Debug, agregando generatePublisherEvidence = false en su configuración, etc.), entonces es probable que el problema sea con su propio código.
Intente que su código se ejecute sin usar sc.Run () (es decir, ejecute el código que sc.Run () habría ejecutado).
Este problema generalmente ocurre cuando falta alguna referencia en su ensamblaje y generalmente el enlace falla en el tiempo de ejecución.
para depurar ponga Thread.Sleep(1000) en la main() . y poner un punto de quiebre en la siguiente línea de ejecución.
Luego, inicie el proceso y adjunte el depurador al proceso mientras está comenzando. Presione f5 después de que llegue al punto de ruptura. Lanzará la excepción de ensamblaje o referencia faltante.
Espero que esto resuelva este error.
Si está utilizando el código Debug como se indica a continuación en su servicio, puede surgir el problema.
#if(!DEBUG)
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[]
{
new EmailService()
};
ServiceBase.Run(ServicesToRun);
#else
//direct call function what you need to run
#endif
Para solucionarlo, mientras construye su servicio de Windows, elimine la condición #if porque no funcionó como está.
Utilice el argumento para el modo de depuración en su lugar, como se muestra a continuación.
if (args != null && args.Length > 0)
{
_isDebug = args[0].ToLower().Contains("debug");
}
En mi caso, el problema era que faltaba la versión de .net framework .
Mi servicio usado
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
Pero la versión del servidor de .net Framework era 4, por lo que al cambiar de 4.5 a 4 se solucionó el problema:
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
Esto funcionó para mí. Básicamente, asegúrese de que el usuario de inicio de sesión esté configurado correctamente. Sin embargo, depende de cómo esté configurada la infraestructura de la cuenta. En mi ejemplo, usa credenciales de usuario de la cuenta AD.
En el cuadro de búsqueda del menú Inicio, busque ''Servicios''. En Servicios, encuentre el servicio requerido, haga clic derecho y seleccione la pestaña Iniciar sesión. Seleccione ''Esta cuenta'' e ingrese el contenido / credenciales necesarios. Escúchelo e inicie el servicio como siempre.
En caso de que tenga un formulario de Windows utilizado para las pruebas, asegúrese de que el objeto de inicio siga siendo el servicio y no el formulario de Windows.
Tenemos Log4Net configurado para iniciar sesión en una tabla de base de datos. La tabla había crecido tanto que el servicio estaba agotando el tiempo tratando de registrar mensajes.
abra la ventana de servicios como administrador, luego intente iniciar el servicio. Eso funcionó para mí.
- Desarrollar proyecto en modo de lanzamiento.
- Copie todos los archivos de la carpeta de lanzamiento a la ruta de origen.
- Ejecute el servicio de ventana usando la ventana del símbolo del sistema en acceso administrativo.
- Nunca borre archivos de la ruta de origen.
En alquiler, esto funciona para mí.
Una vez trate de ejecutar su archivo exe. Tuve el mismo problema, pero cuando lo ejecuté directamente haciendo doble clic en el archivo exe, recibí un mensaje sobre la versión de .NET Framework, porque me lanzaron el proyecto de servicio con un marco que no estaba instalado en la máquina de destino.
La versión de lanzamiento no me funcionaba, sin embargo, busqué en mi visor de eventos y en el registro de la aplicación y vi que el servicio de Windows lanzaba una excepción de seguridad cuando intentaba crear un registro de eventos. Lo arreglé agregando el origen del evento de forma manual con acceso de administración.
Seguí esta guía de Microsoft:
- abrir el editor de registro, ejecutar -> regedit
- Busque la siguiente subclave de registro: HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services / Eventlog / Application
- Haga clic con el botón derecho en la subclave de la aplicación, señale Nuevo y luego haga clic en Clave.
- Escriba el nombre de origen del evento utilizado en su servicio de Windows para el nombre de la clave.
- Cierre el Editor del Registro.
Mi problema se debió al marco de destino mencionado en la configuración del servicio de Windows
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
</startup>
y mi servidor en el que intenté instalar el servicio de Windows no era compatible con esta versión .Net.
Cambiando cual, pude resolver el problema.