TerminateProcess geht nicht die Zweite

[QuickAndDirty]

Also folgender Faden hat mir nicht geholfen
http://www.delphipraxis.net/22108-te...-geht-net.html

Da wir mittlerweile einen Haufen an Diensten installieren die zum Teil auch von einander abhängig sind und je nach Datensicherungsprogramm während der Datensicherung geschlossen sein müssen liefern wir seit einiger Zeit zusätzlich einen Guard der Diese Dienste überwacht aus....

Dieser Guard managed die Laufzeit der Dienste und überwacht zusätzlich deren Funktionalität...sollte also ein Programm über einen Timeout "hängen" stoppt er den Dienst. Sollte das nicht funktionieren (Dienst nach Timeout immer noch in der Prozessliste), dann Führt er TerminateProcess aus.

Das läuft soweit auch.


Nur bei einem einzigen Kunden nicht...... :(

Da versagt Terminateprocess bei einem der Dienste...immer.

Woran kann das liegen.
Folgende "Fehlerquellen" sind bekannt:
-Prozess vom User System kann/soll mann nicht terminieren. (Ist ok, deswegen laufen alle Prozesse als Administrator)
-Prozess von einem anderen User kann/soll man nicht terminieren. (Ist ok, alle laufen im User Kontext Administrator)

Vermutung:
Im Services.msc steht der hängende Prozess als "Wird beendet.."
kann es sein das TerminateProcess nicht funktioniert während der Dienst beendet zu werden versucht?

[Christian Seehase]

Moin QuickAndDirty,

gibt es im Eventlog irgenwelche dazu passenden Einträge?

[Dezipaitor]

Wenn du ein Dienst mit Terminateprocess beendest, dann ist er weg, ohne irgendwen zu informieren. Das ist, als ob der Boden unter den Füßen weggezogen wird. D.h. der ServiceManager bekommt das selbst erst mit, wenn er denn auch danach sucht (sprich jemand aktualisiert es). Schau mal in den Eigenschaftgen im SM, ob da der Starten button wieder aktiv ist.
Außerdem kannst du mal ProcessExplorer angucken, ob der Prozess noch aktiv ist. Wenn ja, dann hast du ein anderes Problem. Wenn ein Prozess in einem nicht unterbrechbaren Interrupt fest hängt, dann kann TerminateProcess das auch nicht schneller machen.

[Zacherl]

Um den Service zu beenden, würde ich wie Dezipiator schon angedeutet hat, lieber direkt die Service Manager API verwenden. Auch bei normalen Prozessen ist ein TerminateProcess() zu vermeiden.

Ich hatte irgendwo mal eine Implementation gesehen, welche einfach ExitProcess() in den Zielprozess injiziert. Das ist zwar etwas umständlich, aber es gibt dem Zielprozess wenigstens Zeit, eventuelle Finalizations auszufüren.

[mleyen]

Zitat:

Zitat von Zacherl (Beitrag 1105241)

Ich hatte irgendwo mal eine Implementation gesehen, welche einfach ExitProcess() in den Zielprozess injiziert. Das ist zwar etwas umständlich, aber es gibt dem Zielprozess wenigstens Zeit, eventuelle Finalizations auszufüren.

http://www.delphipraxis.net/1061510-post3.html

[QuickAndDirty]

Zitat:

Zitat von Christian Seehase (Beitrag 1105112)

Moin QuickAndDirty,

gibt es im Eventlog irgenwelche dazu passenden Einträge?

Arg...das offensichtliche leider noch nicht geprüft, danke!

[QuickAndDirty]

Zitat:

Zitat von Dezipaitor (Beitrag 1105114)

Wenn du ein Dienst mit Terminateprocess beendest, dann ist er weg, ohne irgendwen zu informieren. Das ist, als ob der Boden unter den Füßen weggezogen wird. D.h. der ServiceManager bekommt das selbst erst mit, wenn er denn auch danach sucht (sprich jemand aktualisiert es). Schau mal in den Eigenschaftgen im SM, ob da der Starten button wieder aktiv ist.
Außerdem kannst du mal ProcessExplorer angucken, ob der Prozess noch aktiv ist. Wenn ja, dann hast du ein anderes Problem. Wenn ein Prozess in einem nicht unterbrechbaren Interrupt fest hängt, dann kann TerminateProcess das auch nicht schneller machen.

Der Prozess ist in der Prozessliste immernoch vorhanden...und wird permanent alle paar sekunden versucht vom Guard beendet zu werden...

Aber im in der Prozessliste (Taskmanager) kann ich ihn per Prozessbeenden stoppen.

[QuickAndDirty]

Zitat:

Zitat von Zacherl (Beitrag 1105241)

Um den Service zu beenden, würde ich wie Dezipiator schon angedeutet hat, lieber direkt die Service Manager API verwenden. Auch bei normalen Prozessen ist ein TerminateProcess() zu vermeiden.

Wir versuchen den Dienst regulär zu stoppen, erst wenn er nach X Sekunden dann noch als Prozess existiert eskalieren wir zu TerminateProcess.

Zitat:

Zitat von Zacherl (Beitrag 1105241)

Ich hatte irgendwo mal eine Implementation gesehen, welche einfach ExitProcess() in den Zielprozess injiziert. Das ist zwar etwas umständlich, aber es gibt dem Zielprozess wenigstens Zeit, eventuelle Finalizations auszufüren.

Sagt mir so gar nichts. sorry. ExitProcess ist der Befehl der am Ende von Application.terminate ausgeführt wird? Oder wie darf ich mir das vorstellen? (ja ich schau gleich in der Hilfe nach, no prob)


Wie sähe die Eskalationsreihenfolge also aus?
1. Stoppen des Dienstes
2. Exitprocess Injecten
3. TerminateProcess

????
aber wieso funzt Terminate Process nicht? (über 14 stunden hinweg)

[CCRDude]

Zitat:

Zitat von QuickAndDirty (Beitrag 1105093)

Folgende "Fehlerquellen" sind bekannt:
-Prozess vom User System kann/soll mann nicht terminieren. (Ist ok, deswegen laufen alle Prozesse als Administrator)
-Prozess von einem anderen User kann/soll man nicht terminieren. (Ist ok, alle laufen im User Kontext Administrator)

Das ist noch nicht zwingend ok, der Administrator ist ja auch nicht von Haus aus allmächtig, sei es wegen UAC ab Vista oder wegen fehlender Privileges. Selbst ein Service, der als LocalSystem läuft und mehr darf als ein Admin, darf ohne weiteres auch noch nicht alles.

Frage 1: um welches OS handelt es sich?

Frage 2: Hat der Guard evtl. noch kein SeDebugPrivilege? Aber der Service läuft ja vermutlich als LocalSystem und ist somit noch "über" dem Admin. Also: SeDebugPrivilege nicht planlos verwenden, aber schauen ob es notwendig sein könnte.

Weiter mit noch was einfacherem... aus der Doku:

Zitat:

The handle must have the PROCESS_TERMINATE access right.

Frage 3: Prüfst Du, ober der Handle, den Du TerminateProcess übergibst, überhaupt korrekt erhalten wurde? Oder schlägt der fehl, loggst Du dann GetLastError? Ich weiß, eigentlich eine dumme Frage, aber Du glaubst nicht wie oft hier an der Fehlerbehandlung geschludert wird...

[QuickAndDirty]

Zitat:

Zitat von CCRDude (Beitrag 1105596)

Zitat:

Zitat von QuickAndDirty (Beitrag 1105093)

Folgende "Fehlerquellen" sind bekannt:
-Prozess vom User System kann/soll mann nicht terminieren. (Ist ok, deswegen laufen alle Prozesse als Administrator)
-Prozess von einem anderen User kann/soll man nicht terminieren. (Ist ok, alle laufen im User Kontext Administrator)

Das ist noch nicht zwingend ok, der Administrator ist ja auch nicht von Haus aus allmächtig, sei es wegen UAC ab Vista oder wegen fehlender Privileges. Selbst ein Service, der als LocalSystem läuft und mehr darf als ein Admin, darf ohne weiteres auch noch nicht alles.

Beide laufen mit den rechten des Domänen Administrators...sollte der Guard besser als Lokalessystem angemeldet sein?

Zitat:

Zitat von CCRDude (Beitrag 1105596)

Frage 1: um welches OS handelt es sich?

Entweder 2008 oder Windows 7
Keine Ahnung welches Servicespack oder Build.
Aber es poppt keine UAC auf wenn man was macht.

Zitat:

Zitat von CCRDude (Beitrag 1105596)

Frage 2: Hat der Guard evtl. noch kein SeDebugPrivilege? Aber der Service läuft ja vermutlich als LocalSystem und ist somit noch "über" dem Admin. Also: SeDebugPrivilege nicht planlos verwenden, aber schauen ob es notwendig sein könnte.

Ich weiß nicht mal was das SeDebugPrivilge ist...
Und auch im einrichten von Gruppenrichlinien oder verwalten von Active-Directories habe ich keine Ahnung....aber soweit ich weiß sind das zwei Stichwörter die erfunden wurden um die Kreativität der Entwickler zu behindern.

Ich sollte den Guard wirklich mal als LocalesSystem anmelden, hmm?

Zitat:

Zitat von CCRDude (Beitrag 1105596)

Weiter mit noch was einfacherem... aus der Doku:

Zitat:

The handle must have the PROCESS_TERMINATE access right.

Frage 3: Prüfst Du, ober der Handle, den Du TerminateProcess übergibst, überhaupt korrekt erhalten wurde? Oder schlägt der fehl, loggst Du dann GetLastError? Ich weiß, eigentlich eine dumme Frage, aber Du glaubst nicht wie oft hier an der Fehlerbehandlung geschludert wird...

[/QUOTE]
Oh je....
Der Guard wurde von einem Kollegen geschrieben und ich schaue mal ob da irgendwo getlasterror aufgerufen wird....aber ich bezweifle es (weil der produziert auch so Code zeilen wie

Code:

If not(b<>False) Then

diese)

Das überwachte Programm ist von mir...und der eigentliche Fehler ist ja auch das es sich aufhängt und erst notwendig macht das der Guard es abschießen/neustarten möchte.
Ich kämpfe hier also ein 2 Fronten...beim Kunden versuche ich zu ermitteln warum es abstürzt und das reicht dem Kollegen um selbst in sachen Guard NICHT tätig zu werden...deswegen bin ich es hier der diesen Thread auf gemacht hat
(ja unsere Firma ist ein Kindergarten).