![]() |
Service-EXE ist in Windows Audio geöffnet?
Moinsen...
Ich schreibe an einem Systemdienst. Wenn ich den Dienst in der Dienstverwaltung beende und anschließend neu kompiliere, dann sagt der Compiler, dass die EXE nicht erstellt werden kann. Wenn ich versuche, die EXE manuell im Explorer zu löschen, erhalte ich die Fehlermeldung, dass das nicht geht weil die EXE in "Windows Audio" geöffnet ist. Wenn ich nun den Dienst "Windows-Audio" beende und versuche, die EXE zu löschen, geht das auch nicht weil sie nun angeblich in "DHCP-Client" geöffnet wäre. Und so weiter... Ich vermute, dass das irgendwas mit Dependencies zu tun hat. Hat jemand eine Idee? Grüße Cody |
AW: Service-EXE ist in Windows Audio geöffnet?
Ein Systemdienst blockt und die Erkennung geht wohl auf die PIDs, welche in diesem Fall, vermutlich Dank fehlender Rechte, nicht ausgelesen werden können.
Alle diese Prozesse haben also die PID 0 und als Name wird nun der des zuerst gefundenen Prozesses ausgelesen. :stupid: ProcessExplorer? |
AW: Service-EXE ist in Windows Audio geöffnet?
Bei Windows XP kann man sich in der Systemsteuerung bei den Diensten die Abhängigleiten zwischen den Diensten anschauen. Wie's bei anderen Windosen ist, weiß ich nicht und mag auch nicht danach suchen.
Aber: In der Registry könntest Du eventuell unter
Delphi-Quellcode:
fündig werden.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Dort müssten alle Dienste aufgeführt sein und bei Abhängigkeiten müsstest Du dort jeweils bei
Delphi-Quellcode:
und/oder
DependOnService
Delphi-Quellcode:
herausbekommen können, wer da von wem abhängt.
DependOnGroup
Eventuell forschst Du mal von hier ![]() |
AW: Service-EXE ist in Windows Audio geöffnet?
Zitat:
Neue Vermutung: Ich versuche, den Service aus sich selbst heraus zu beenden, wenn intern eine Exception aufgetreten ist und die entsprechenden Fehler im EvtLog geschrieben sind. Könnte es sein, dass ein MyService.Free den Dienst nicht richtig beendet? |
AW: Service-EXE ist in Windows Audio geöffnet?
Ein Service wird eigentlich mit
Delphi-Quellcode:
beendet.
MyServiceThread.Terminate
Damit müsste er eigentlich dem Betriebssystem mitteilen, dass er sich nun verabschiedet. (das ist Müll, da hab' ich (mal wieder) zu schnell diagonal gelesen :-( Wenn dass nicht passiert, ist zwar des Programm selbst beendet, das Betriebssystem weiß davon aber nichts. (Bin mir aber nicht sicher, ob das ausreicht.) Eventuell ist das hier beschriebene aber hilfreicher: ![]() Schau Dir bitte bei Gelegenheit mal diese Seite an: ![]() |
AW: Service-EXE ist in Windows Audio geöffnet?
Delphi-Quellcode:
:roll: (das Application aus der Service-Unit und nicht das aus Forms)
Application.Terminate;
|
AW: Service-EXE ist in Windows Audio geöffnet?
Zitat:
EDIT: Ich habe mal folgendes eingefügt:
Delphi-Quellcode:
Wenn jetzt während der Initialisierung eine Exception auftritt sagt mir der Dienstmanager, dass der Dienst gestartet und dann angehalten wurde. Der Effekt, dass unter SvHost weiterhin ein "Restprozess" verbleibt, hat sich dadurch leider aber nicht verändert.
procedure TMyService.Kill;
const SERVICE_CONTROL_STOP = $00000001; begin ServiceController(SERVICE_CONTROL_STOP); end; Noch ein EDIT: Ich habs rausgefunden! Problem liegt ganz woanders. Ich habe für die Ereignisanzeige eine MessageTable direkt in die Exe von meinem Dienst einkompiliert und verweise in der Registry als MessageFile darauf. Wenn ich nun die Ereignisanzeige öffne, baut diese ein Handle zum Image (EXE-Datei) auf und lässt es so lange offen bis ich die Ereignisanzeige wieder schließe. Problem erkannt, Gefahr gebannt: Ich kompiliere mir jetzt als MessageFile eine separate DLL und gut ist. Am Rande bemerkt finde ich die Methodik, Einträge ins Eventlog zu schreiben, ziemlich abartig kompliziert. Wer auch immer sich das so für NT 3.5 damals ausgedacht hat, er muss ein selbstverliebter Theoretiker gewesen sein :-D |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz