TerminateProcess geht nicht die Zweite

[CCRDude]

Zitat von QuickAndDirty:

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 von CCRDude:

Zitat von QuickAndDirty:

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 von CCRDude:

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 von CCRDude:

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 von CCRDude:

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).

[mkinzler]

If not(b<>False) Then ist ja echt abenteuerlich

[CCRDude]

Als "LocalSystem" (nicht "LokalesSystem") kannst Du Dich nicht einfach so anmelden; Systemdienste etwa arbeiten unter diesem Account, manchmal auch LocalService, NetworkService sowie einige andere. Wenn Du im Windows Task Manager Dir die Prozesse aller User anzeigen lässt, wirst Du die (unter leicht anderem Namen) sehen. Das halt also nichts mit der Domäne zu tun.

Privileges betreffen Rechte, die sich ein Programm teilweise erst noch anfordern muss. Siehe auch MSDN: How to Use the SeDebugPrivilege - da wird sogar die OpenProcess/TerminateProcess-Thematik erwähnt.

Und nein, Privileges und auch Gruppenrichtlinien wurden nicht erfunden, um Programmierer zu ärgern, sondern in diesem Kontext auch, um Sicherheit zu schaffen - was zugegeben Programmierer manchmal zwingt, sich Gedanken über Sicherheit zu machen, was ich allerdings nicht als Ärgern einstufen würde

Ich glaube aber ehrlich gesagt, der Kindergarten ist die größere Baustelle Eigentlich würde ich ja empfehlen, euch ein bisschen in Tokens und Privileges einzulesen, aber ich glaube da täte erstmal ein Kommunikations und ggfls. Führungsseminar not, wenn jemand in einer kundenkritischen Situation einfach so Fehler in seinem Programm ignorieren darf

[QuickAndDirty]

Gelöst ---
Ursache Eine Quelloffene Treiber-DLL im System-Verzeichis wurde genutzt um per IP einen Hardware in der Virtuellen Maschine des Kunden verfügbar zu machen.

Wann immer der IP Server mit dem die DLL sich verband, aus welchen gründen auch immer, nicht rechtzeitig antwortete, meldete sie es mit "::MessageBox" aufrufen....

Leider kann man wohl ein Programm nicht abschießen wenn es in einer System DLL hängt und im dienst ist die MessageBox ja nicht sichtbar.


1.
Mal ne frage aus Neugierde: Dürfen System DLLs überhaupt Messageboxen aufmachen? Weil das ist ja mit hinblick auf einen gebrauch in einem Dienst ziemlich suboptimal.

2.
Kann ich von außen herausfinden ob ein Dienst gerade in einer Messagebox hängt und diese "drücken".


Wir haben es jetzt so geregelt das wir besagter mini dienst die Hardware selbst direkt benutzt....
und jetzt seit einigen Tagen keine Probleme mehr ^^

[CCRDude]

1. Hängt sicherlich etwas damit zusammen, was Du unter Treiber-DLL bzw. System-DLL meinst. Ist es ein richtiger Treiber, sicherlich nicht. Meinst Du aber nur die Funktionalität - kann ja sein, daß die auch in einer normalen Anwendung eingebunden werden kann/soll. Dann ist es nur noch schlechter Stil Zudem lassen sich System Services per Flag auf "interaktiv" setzen. In älteren Windows-Versionen (Windows 2000?) war dieses Flag evtl. nicht notwendig, später kam es aus Absicherungsgründen hinzu (Prozesse mit Systemrechten sollten nicht direkt über das UI mit dem Benutzer kommunizieren).

2. "Einfacher" wäre es vermutlich, die MessageBox-Funktion innerhalb des Prozesses zu hooken und so einfach zu ignorieren (oder, um's ganz fein zu machen, ins Eventlog umzuleiten). Dazu gibt's hier in der DP glaub ich auch Beispiele

[QuickAndDirty]

Ok, auch wenn es Offtopic in bezug auf den Threadtitel ist...es ist ja noch der selbe Fall...

Zitat von CCRDude:

1. Hängt sicherlich etwas damit zusammen, was Du unter Treiber-DLL bzw. System-DLL meinst.
Ist es ein richtiger Treiber, sicherlich nicht.

Ich meine ein Datei in C:\Windows\System32 es ist kein Treiber nur eine DLL die systemweit und von jeder X beliebigen Anwendung - oder auch Dienst - benutzt werden können sollte. Ist eben eine Capi2032.dll von Shamrock und dazu gibt es irgendwie zwischen 16Kb und 32Kb Opensource C++ Code... ich verwende die ja auch...aber ich muss mich nicht auf das dauerhafte Funktionieren dieser Geschichte verlassen...

CAPI ist für schon so die Schnittstelle zur ISDN-Karte...sollte eigentlich(wenn es verkauft werden würde und nicht umsonnst Opensourcezeug ist) mit der selben Sorgfallt und Misstrauen gegenüber den Randbedingungen programmiert sein wie ein Treiber.

Zitat von CCRDude:

Meinst Du aber nur die Funktionalität - kann ja sein, daß die auch in einer normalen Anwendung eingebunden werden kann/soll. Dann ist es nur noch schlechter Stil Zudem lassen sich System Services per Flag auf "interaktiv" setzen. In älteren Windows-Versionen (Windows 2000?) war dieses Flag evtl. nicht notwendig, später kam es aus Absicherungsgründen hinzu (Prozesse mit Systemrechten sollten nicht direkt über das UI mit dem Benutzer kommunizieren).

Das wäre leider keine lösung...aber da es Opensource ist...vielleicht werde ich mal in nem C++ board betteln das jemand mir den code ohne "::MessageBox" kompiliert...habe hier keine IDE dafür und betteln ist schneller als mich mit ner gnu C++ und Eclipse oder MS C++ und VS ... rumzuschlagen.
Es ist jetzt nicht WIRKLICH entscheidend, aber es wäre sicher von Vorteil für so manchen wenn es das Projekt so gäbe das es auch in Diensten funktioniert....
(Ich bereite morgen mal nen freundlich Text vor und Kommentiere die MessageBoxen aus)

Zitat von CCRDude:

2. "Einfacher" wäre es vermutlich, die MessageBox-Funktion innerhalb des Prozesses zu hooken und so einfach zu ignorieren (oder, um's ganz fein zu machen, ins Eventlog umzuleiten). Dazu gibt's hier in der DP glaub ich auch Beispiele

Vermutlich nicht "Einfacher", aber da ich ja im Prinzip immer damit rechnen muss das irgendwelche von meinen Diensten genutzten Treiber oder Bibliotheken oder sonnst etwas eine MessageBox werfen kann, würde es wohl der Stabilität des Produktes entgegenkommen, wenn ich den von dir vorgeschlagenen Weg einschlage.

Muss also was über Hooks lernen *nicht will*