Update fertig und hochgeladen. Im Edit wird nun auch der Parentprozess angezeigt. Durch Rechtsklick ins Listview wird ein Popupmenü aufgerufen, bei dem man unter anderem auch den markierten Prozess beenden kann. VORSICHT! Anders als im Taskmanager können hier auch Systemprozesse beendet werden.

AHT hat folgendes geschrieben:

Anders als im Taskmanager können hier auch Systemprozesse beendet werden.

Wie hast du das gemacht?

Nettes Programm

hier noch ein paar anregungen:

wenn du im onResize der Form die Größe der Grid und des Textfeldes Anpassen würdes wäre es zum Teil wesentlich übersichtlicher.

ansonsten wäre eine Speicherfunktion (evtl. auch das automatische Speichern des logs) nicht schlecht

Ich habe eine ganze Menge blaue Dreiecke...was mich nur wundert ist das die meisten Prozesse nur mit wenigen Sekunden ausgeschildert sind, obwohl der Rechner den ganze nTag an war, speziell ICQ.

Hier habe ich mal Fraps..

PID: 4656
Prozessname: fraps.exe
Prozesspfad: C:\Fraps\fraps.exe
Startzeit des Prozesses: 30.11.2007 um 22:08Uhr, 50sec 656millisec
Zeit des Prozesses im Kernelmode: 609ms
Zeit des Prozesses im Usermode: 2sec 468ms
PID des Elternprozesses: 396
Adresse des PEB's: 2147323904
Geöffnet mit Zugriffsrechten: $1F0FFF
Anzahl geöffneter Handles auf den Prozess: 3
Pointer Count: 33
Exitcode: 259
Anzahl geöffneter Handles auf Hooks: 3



Warum wird da eine Zeit von 609ms bzw. 2sec 468ms angezeigt?

Luckie hat folgendes geschrieben:

AHT hat folgendes geschrieben: Anders als im Taskmanager können hier auch Systemprozesse beendet werden. Wie hast du das gemacht?

Der Taskmanager von NT-basierenden Systemen hat eine Art "Sicherheitssperre" eingebaut. Auch wenn die Rechte auf einen jeweiligen Prozesse ausreichen, kann ein User einen Systemprozess, wie z.B. LSASS.EXE, nicht beenden.

Grund dafür:
Der Taskmanager überprüft den Prozessnamen und beendet den jeweiligen Prozess nicht, wenn dieser der eines "Systemprozesses" ist (bei XP u.a. CSRSS.EXE, WINLOGON.EXE, LSASS.EXE).

Manchze unbegaben "Programmierer" nutzen diese Tatsache zum Erstellen von Vieren und nennen ihren Virus eionfach CSRSS.EXE, damit dieser nicht vom Taskmanager beendet werden kann.

Mein Tool macht diese Sicherheitsabfrage nicht, was beim Beenden solcher Prozesse über das Tool zu derben Systemabstürzen führen kann.

Zyklame hat folgendes geschrieben:

Nettes Programm hier noch ein paar anregungen: wenn du im onResize der Form die Größe der Grid und des Textfeldes Anpassen würdes wäre es zum Teil wesentlich übersichtlicher. ansonsten wäre eine Speicherfunktion (evtl. auch das automatische Speichern des logs) nicht schlecht

Ja, da hast du recht, habe auch schon darüber nachgedacht. Mein "Delphiclone", den ich hier zum Programmieren nutze, unterstützt aber nur unzureichend Callbacks, die auf die eigene EXE zeigen. Um das mit deser Programmiersprache vernünftig durchführen zu können, müsste ich eine extra DLL schreiben - und das war mir zuviel Aufwand für diesen Test.

teamrocket0 hat folgendes geschrieben:

Ich habe eine ganze Menge blaue Dreiecke...was mich nur wundert ist das die meisten Prozesse nur mit wenigen Sekunden ausgeschildert sind, obwohl der Rechner den ganze nTag an war, speziell ICQ. Hier habe ich mal Fraps.. PID: 4656 Prozessname: fraps.exe Prozesspfad: C:\Fraps\fraps.exe Startzeit des Prozesses: 30.11.2007 um 22:08Uhr, 50sec 656millisec Zeit des Prozesses im Kernelmode: 609ms Zeit des Prozesses im Usermode: 2sec 468ms PID des Elternprozesses: 396 Adresse des PEB's: 2147323904 Geöffnet mit Zugriffsrechten: $1F0FFF Anzahl geöffneter Handles auf den Prozess: 3 Pointer Count: 33 Exitcode: 259 Anzahl geöffneter Handles auf Hooks: 3 Warum wird da eine Zeit von 609ms bzw. 2sec 468ms angezeigt?

In der Zeit, in der ein Prozess zum Beispiel auf Eingaben wartet oder ein anderer Prozess gerade Prozessorzeit hat, wird dieser vom Prozessor nicht ausgeführt. Fraps hat hier 2sec und 468ms in Virtuellen Speicherbereichen unterhalb von 2GB herumgefummelt und 609ms wurde für Fraps etwas oberhalb von 2GB getan. Wie lange Fraps auf der faulen Haut gelegen hat oder anderen Prozessen die Arbeit überließ, bleibt hier unberücksichtigt.

So, jetzt noch mals zu der Ursache dieser Zombieprozesse:

Den Usermode habe ich, so denke ich, als Ursache komplett abgegrast - der Parentprozess ist ebenfalls nicht immer der Explorer. Im Usermode, das heißt bei einem laufenden Programm, liegt die Ursache dieser Zombies wohl nicht. Ein Hinweis darauf, das sich die Ursache hier innerhalb eines Treibers befindet, ist meiner Meinung auch der Handlecount von 1.
Objekte werden in Windows meines Wissens nach nicht gelöscht, solange Sie noch irgendwo referenziert sind. Die einzige Möglichkeit, dies im Usermode zu tun, ist meines Wissens nach durch das Öffnen eines Handles auf das Objekt - im Kernel gibt es da scheinbar auch noch andere Möglichkeiten.
Das eine geöffnete Handle rührt von meinem Testprozess her - als der Prozess beendet wurde, war also kein Handle auf diese Prozesse geöffnet. Desweiteren werden keine Zombies erzeugt, wenn der Rechner im Abgesicherten Modus gestartet wird.

Ich gehe deshalb im Augenblick immer mehr davon aus, dass die Ursache für das Entstehen dieser Zombieprozesse ein Fehlerhaft programmierter (?Hardware?-) Treiber ist.

Gerade bei Rechnern, die Tag und Nacht laufen müssen, dürften solche Zombieprozesse schon etwas problematisch werden. Zwar wird jedesmal nur recht wenig Speicher dabei verpulvert und nicht wieder freigegeben, eine PID muss aber auch jedesmal dran glauben.

Wenn es einer besser weiß, sollte er mich hier korrigieren:
Eine PID dürfte ein Index eines Eintrages innerhalb einer Liste im Kernel (Virtueller Speicher oberhalb von 2GB) sein, der wiederum auf die Adresse dieses Prozess-Objektes im Kernel verweist. Die maximale Anzahl an solchen Idexes dieser Liste dürfte auf 16BIT (oder ?32Bit?), also 65535 (?4294967296?) Einträge, begrenzt sein. Jeder Prozess belegt vier Eintrage => 16384 (?1073741824?) Prozesse maximal, dann Absturz. Da jeder mit Fenster gestartete Prozess bei seiner Beendung zu einem Zombie wird, dürfte es nicht so ganz unmöglich sein, das dieser Wert erreicht wird.

Könnte man nicht das offene Handle "von Hand" schließen? Ich meine, angenommen, der Treiber braucht das Objekt nicht mehr, hat aber vergessen das Handle zu schließen, dann könnte mans ja selber (per CloseHandle?) schließen, oder?
Auf der Webseite hast du auch irgendwo geschrieben, dass es vermutlich ein NVidia-Treiber sein könnte, was bei mir sogar zutrifft. Könnte man das nicht irgendwie testen indem man testweise einen Standardtreiber von Windows nimmt?

Chryzler hat folgendes geschrieben:

Könnte man nicht das offene Handle "von Hand" schließen? Ich meine, angenommen, der Treiber braucht das Objekt nicht mehr, hat aber vergessen das Handle zu schließen, dann könnte mans ja selber (per CloseHandle?) schließen, oder? Auf der Webseite hast du auch irgendwo geschrieben, dass es vermutlich ein NVidia-Treiber sein könnte, was bei mir sogar zutrifft. Könnte man das nicht irgendwie testen indem man testweise einen Standardtreiber von Windows nimmt?

Es ist ja gerade kein Handle offen! CloseHandle ist eine Funktion aus der Kernel32, also eine Usermode Funktion, das funktioniert in einem Treiber sowieso nicht. Im Treiber ist dafür ZwClose aus der ntoskrnl.exe zuständig - ist aber, wie gesagt, kein Handle offen.
Im Kernel könnte da in diesem Fall DereferenceObject funktionieren, dazu müßte man aber einen Treiber programmieren und zumindestens die Adresse der jeweiligen Prozessobjekte ermitteln. An die Adressen käme ich wohl ran - bin aber im Treiberschreiben noch zu unerfahren. Da dieses Problem auf meinen Rechnern nicht auftritt, müssten die "Tester" solcher Experimente mit BSODs (Blue Screen of Death) rechnen, was evtl. nicht ganz ohne Daten und Hardwareverlust abgehen könnte. Die Ursache durfte das sowieso nicht beseitigen.

Da ich mir demnächst bei Gelegenheit die Treiber nochmals etwas näher betrachten möchte, habe ich noch ein Update des Testprogramms erstellt:
freenet-homepage.de/ahfundgrube/PH.zip
Neben den Prozessen werden nun auch die geladenen Treiber und einige Infos dazu gelistet. Einige eurer Anregungen habe ich ebenfalls umgesetzt.

Die eigentliche Ursache von dem, an das ich da herankommen will, habe ich bislang immer noch nicht gefunden (komme immer nur sporadisch an einen Rechner ran, der diesen Fehler produziert).
Als Nebeneffekt bin ich aber auf einen Fehler in Microangelo Version 5.02 gestoßen. Startet man dort den Icon Explorer und offnet man eine Icon Library, wird jedesmal ein Zombie erzeugt. Die Zombies verschwinden aber wieder, wenn muexplor.exe, der Icon Explorer, wieder geschlossen wird. Hier sieht man auch, das der Handlecount auf 2 steht - ein Handle das muexplor.exe geöffnet hält und nicht wieder freigibt und ein Handle für meinen Testprozess.
Für die, die es interessiert, befindet sich das LOG im Anhang in der ZIP Datei.

PS: Die neueste Version (6) von Microangelo macht es auch nicht besser.

Gruß

AHT

Habe scheinbar die Ursache gefunden. Schuld an den Zombies scheint ein Treiber von Anti-Vir zu sein. Evtl. tritt diese Problem nur auf, wenn ein spezieller anderer Treiber installiert ist - habe da einen Treiber von NVIDIA Grafikkarten im Verdacht.

Wer von euch hat nicht Anti-Vir installiert und sieht mit meiner Testsoftware trotzdem Zombies?
Welche Grafikkarten sind bei den Leuten installiert, die Zombies sehen und Anti-Vir installiert haben?
Hat jemand Vista oder 2000 mit Anti-Vir und sieht Zombies?

Ich sehe reichlich Zombies und habe allerdings Avira in Kombination mit einer ATI Radeon 9600 XT...

Gruß
alias5000

alias5000 hat folgendes geschrieben:

Ich sehe reichlich Zombies und habe allerdings Avira in Kombination mit einer ATI Radeon 9600 XT... Gruß alias5000

Danke! NVIDIA fällt also raus.

Ich habe 2000 mit NVidia und ohne Avira. Hier gibts keine Zombies.

Martok hat folgendes geschrieben:

Ich habe 2000 mit NVidia und ohne Avira. Hier gibts keine Zombies.

Es scheint sich also erst einmal nur um Anti-Vir zu drehen. Ware jemand, der Zombies hat, mal so nett Anti-Vir kurzeitig zu deinstallieren, zu rebooten und nochmals zu testen, um meine "Vermutung" zu belegen, dass es sich um einen Fehler in Anti-Vir handelt? Das LOG lässt sich jetzt mittels Rechtsklick ins Edit auch auf Festplatte bannen (vorausgesetzt ZIP ist enpackt).

Hab mal in ner VM mit Windows XP dein Programm gestartet, auf dem kein AntiVir installiert war, und es wurden keine Zombies gefunden. Dann hab ich AntiVir installiert, und tatsächlich, danach kamen immer mehr Zombieprozesse. Scheint eindeutig an AntiVir zu liegen.

Chryzler hat folgendes geschrieben:

Hab mal in ner VM mit Windows XP dein Programm gestartet, auf dem kein AntiVir installiert war, und es wurden keine Zombies gefunden. Dann hab ich AntiVir installiert, und tatsächlich, danach kamen immer mehr Zombieprozesse. Scheint eindeutig an AntiVir zu liegen.

Konnte den Fehler jetzt auf einem meiner Rechner reproduzieren und auch den "defekten" Treiber ausfindig machen. Der hier ist es:

Zitat:

Treibermodul: avipbb.sys Imagename: \SystemRoot\System32\DRIVERS\avipbb.sys Dateiname: F:\WINDOWS\System32\Drivers\avipbb.sys Ladeadresse: -59719680 Belegt im Speicher: 57344 Bytes Loadcount: 1 Statusflags: 152059904 Bytes Beschreibung des Treibers: Avira Driver for RootKit Detection Interner Name: avipbb.sys Dateiversion: 1.00.02.11 Ursprungs-Dateiname: avipbb.sys Firma: AVIRA GmbH Copyright: Copyright © 1996-2007 AVIRA GmbH. All rights reserved. Produktversion: 7.00.00.00 Kommentar: Avira Driver for RootKit Detection Registriert als Service unter dem Namen: avipbb Registriert als Service unter dem Registryschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet

Danke an euch alle - ihr seid KLASSE!

Fazit: Es sieht ganz so aus, als hätte sich Avira in seinen RootKit Scanner einen Fehler eingebaut.

Dann schreib denen doch ne Mail

alias5000 hat folgendes geschrieben:

Dann schreib denen doch ne Mail

Das habe ich auch vor - mit dem Verweis auf dieses Forum hier, aber evtl. erst morgen.