2009-02-16 10 views
5

Wenn ich die Assemblys in meinem Dienst mit Verisign signntool.exe signiere, kann sie nicht gestartet werden, wenn der Computer auf einem Computer mit Windows 2003 Server gestartet wird. Das Ereignisprotokoll hat zwei Ereignisse:Signierte Assemblies verhindern, dass mein Dienst gestartet wird

"Timeout (30000 Millisekunden) warten auf den xxx Service-Dienst zu verbinden." und "Der xxx Service-Dienst konnte aufgrund des folgenden Fehlers nicht gestartet werden: Der Dienst hat nicht rechtzeitig auf die Start- oder Steuerungsanforderung reagiert."

Es beginnt gut, sobald die Maschine läuft. Es startet gut in XP und Vista. Es beginnt ordnungsgemäß, wenn die Assemblys nicht signiert sind.

Antwort

2

Authenticode, das Ihre Assemblys signiert, kann sich sehr negativ auf den Kaltstart auswirken. Weitere Informationen finden Sie in diesem KB-Artikel.

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

+0

Obwohl das Installieren eines Patches, wo MS sagt, dass es nicht getestet wird, klingt nicht sehr ansprechend auf einem Produktionssystem ... –

1

Wie spacedog sagte, kann Authenticode haben einen schlechten Einfluss auf die Startzeit. Die Frage ist also, was unterschreibst du? Es sollte ausreichen, dass Authenticode nur Ihre ausführbare Datei signiert, die wiederum nur auf stark benannte Assemblys verweist. Daher der Aufwand für die Überprüfung der Authenticode-Signatur.

Sie könnten Ihre Assemblys auf dem GAC installieren - wenn möglich - dies wird die Startleistung leicht erhöhen, da die starke Namensvalidierung übersprungen wird (siehe Authenticode and Assemblies) und/oder Sie könnten auch Ihre Assemblys, wenn die Startzeit immer noch ein Problem ist.

Von der Antwort auf Windows service startup timeout von Romulo 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.

Neben SetServiceStatus könnten Sie auch versuchen, den Service Control Manager (SCM), dass der Dienst zusätzliche Zeit starten muss sagen, durch den Anruf ServiceBase.RequestAdditionalTime.

+0

Diese Antwort scheint Authenticode-Signaturen mit starken Namenssignaturen zu vermischen? – Dave

+1

Nein. Inwiefern? –

+0

(Forts.) Bei Verwendung von Authenticode reicht es aus, dass die referenzierten Assemblies mit starkem Namen signiert sind. Ich habe versucht, eine Referenz zu finden, leider habe ich nur diesen Beitrag gefunden: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/493aca7f-b5ea-4462-a15f-affe874bfe44/ –

4

Dieses Problem tritt bei ausführbaren Dateien mit signiertem .NET-Dienst sehr häufig auf: Der Dienst wird beim Systemstart nicht gestartet, kann jedoch ausgeführt werden, wenn er anschließend manuell gestartet wird. Ob ServiceBase.RequestAdditionalTime verwendet wird, ist irrelevant: Tatsächlich wird überhaupt kein Benutzercode ausgeführt, bevor das Zeitlimit für die Dienststartanforderung überschritten wird. Dieser Effekt ist bei Computern ohne Internetverbindung noch ausgeprägter: In diesem Fall schlägt der manuelle Start des Dienstes vom SCM fehl.

dieses Problem zu beheben, disable the verification of the Authenticode signature at load time in order to create Publisher evidence, indem Sie die folgenden Elemente, um Ihre .exe.config Datei hinzufügen: nur wenn der Service:

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

Verlag Beweis eine wenig befahrene Code Access Security (CAS) Funktion ist verlässt sich auf die PublisherMembershipCondition wird es deaktivieren Probleme verursachen. In allen anderen Fällen führt dies dazu, dass die permanenten oder zeitweiligen Startfehler wegfallen, da die Laufzeit keine kostspieligen Zertifikatsprüfungen (einschließlich Sperrlisten-Lookups) mehr erfordert.

Bearbeiten, Juli 2010: Für Anwendungen, die Version 4.0 von .NET Framework verwenden, ist diese Problemumgehung nicht mehr erforderlich.

Verwandte Themen