2009-02-16 12 views
5

Cuando firmo los ensamblados en mi servicio con el signtool.exe de Verisign, no se inicia cuando se inicia la máquina, en una máquina que ejecuta Windows 2003 Server. El registro de eventos tiene dos eventos:Los ensambles firmados impiden que se inicie mi servicio

"Tiempo de espera (30000 milisegundos) esperando que se conecte el servicio xxx Service". y "El servicio xxx no se pudo iniciar debido al siguiente error: El servicio no respondió a la solicitud de inicio o control en el momento oportuno".

Se inicia correctamente una vez que la máquina está en funcionamiento. Comienza bien en XP y Vista. Comienza bien cuando los ensamblajes están sin firmar.

Respuesta

2

Authenticode la firma de sus ensamblajes puede tener un efecto muy negativo en el arranque en frío. Vea este artículo de KB para más detalles.

http://support.microsoft.com/default.aspx/kb/936707

+0

Aunque instalar un parche donde MS dice que no se ha probado no suena muy atractivo en un sistema de producción ... –

1

Como dijo spacedog, Authenticode puede tener un impacto negativo en el tiempo de inicio. Entonces, la pregunta es ¿qué estás firmando? Debería ser suficiente para que Authenticode firme solo su ejecutable de servicio, que a su vez solo debe hacer referencia a los ensamblajes nombrados fuertes. Por lo tanto, la sobrecarga de verificar la firma de Authenticode.

Puede instalar sus ensamblajes en el GAC, si es posible, esto aumentará ligeramente el rendimiento de inicio porque se omite la validación de nombre fuerte (consulte Authenticode and Assemblies) y también puede agregar ensamblajes si el tiempo de inicio todavía es un problema.

De la respuesta a Windows service startup timeout por Rómulo A. Ceccon:

It's good practice to finish starting your service as fast as possible. So, during the start state, do only what you absolutely need to acknowledge it started successfully; and do the rest later. If the start is still a lengthy process, use SetServiceStatus periodically to inform the Service Control Manager that you have not yet finished, so it does not time-out your service.

Además de SetServiceStatus también se podría tratar de decirle al Administrador de control de servicios (SCM) que el servicio necesita más tiempo para poner en marcha llamando al ServiceBase.RequestAdditionalTime.

+0

¿Esta respuesta parece combinar firmas de Authenticode con firmas de nombres fuertes? – Dave

+1

No. ¿En qué manera? –

+0

(continuación) Al utilizar Authenticode, es suficiente que los ensamblados a los que se hace referencia tengan firmado el nombre fuerte. Estaba intentando encontrar una referencia, lamentablemente solo encontré esta publicación: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/493aca7f-b5ea-4462-a15f-affe874bfe44/ –

4

Este problema es muy común para ejecutables de servicio .NET firmados: el servicio no se iniciará en el momento del arranque, pero se ejecutará correctamente cuando se inicie manualmente después. Si se usa ServiceBase.RequestAdditionalTime es irrelevante: de hecho, ningún código de usuario se ejecuta en absoluto antes de que la solicitud de inicio del servicio expire. Este efecto es aún más pronunciado en máquinas sin conectividad a Internet: en ese caso, incluso el inicio manual del servicio desde el SCM fallará.

Para resolver este problema, disable the verification of the Authenticode signature at load time in order to create Publisher evidence, mediante la adición de los siguientes elementos para su archivo exe.config:

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

pruebas Editor es una característica poco usada Código de Acceso de Seguridad (CAS): sólo si su servicio se basa en PublisherMembershipCondition lo 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).

edición, julio de 2010: Para aplicaciones que utilizan la versión 4.0 de .NET Framework, ya no se requiere esta solución.

Cuestiones relacionadas