Entwickler-Ecke :: Thema anzeigen - Merkwürdigkeiten in Windows (XP)

Entwickler-Ecke

Sonstiges (Delphi) - Merkwürdigkeiten in Windows (XP)

AHT - Do 08.11.07 21:46
Titel: Merkwürdigkeiten in Windows (XP)

Hier habe ich mal eine kleine Merkwürdigkeit zum Testen unter NT-basierenden Systemen (Vista, XP und 2000 vor allen Dingen).
http://freenet-homepage.de/ahfundgrube/PH.zip
Das Proggie zeigt beim Start laufende Prozesse an und gibt im Edit rechts einige erhaltene Daten zurück und scannt PIDs.

Problem: Auf einigen (wenigen) Rechnern werden nicht nur Prozesse mit grünen Dreiecken angezeigt, sondern auch PIDs mit blauen Dreiecken (und ich weiß beim besten Willen nicht warum). Einen Fehler von mir schließe ich aus, es muss an Windows oder an laufenden Systemprogrammen liegen. Ich möchte nun gerne wissen, bei wem nur grüne Dreiecke zu sehen sind, wer auch blaue Dreiecke sieht und was genau im Edit steht (lässt sich mit Rechtsklick kopieren und einfügen). Keine Angst, die blauen PIDs sind in der Regel keine RootKits, die meisten verstecken sich besser - da wird scheinbar nur im Speicher etwas nicht gelöscht.

Also:
Wer sieht nur grüne Dreiecke, wer sieht auch blaue Dreiecke und was steht im Edit.
Bei allen, die bislang blaue Dreiecke gesehen haben, war irgendetwas auf dem Rechner nicht so, wie es sein sollte - also Zusatzfrage für die "Blauen":
- Läuft der Rechner auffällig langsam?
- Stürzt da öfters mal was ohne ersichtlichen Grund ab?
- etc...

Programm starten (am besten direkt nach dem Booten) und während des Scans auf keinen Fall irgendwelche anderen Programme starten oder beenden (Scan dauert ein paar Sekunden). Wer blaue Dreiecke sieht, sollte nach einiger Zeit (in dieser Zeit bitte auch was am PC machen) nochmals Scannen und auch das zweite Ergebnis hier posten.
Ich möchte gerne Wissen, ob das mit den blauen Dreiecken öfters auftritt und bitte (bitte bitte) deshalb um rege Beteiligung.
Will hoffen, das es überall funzt - sitzt einiges an Native API drin.
user defined image

Gruß und besten Dank

AHT

Chryzler - Do 08.11.07 21:59

Der Link ist kaputt. :o

EDIT: Ok geht jetzt.

Also bei mir tauchen genau 58 PIDs mit blauem Pfeil auf. Die meisten liefen nur ungefähr 100 ms, ein paar jedoch auch ungefähr eine Minute. Ist das normal? :|

AHT - Do 08.11.07 22:04

Chryzler hat folgendes geschrieben:

Der Link ist kaputt. :o

OK, jetzt mal versuchen (?Kaum gepostet und schon das erste Problem? :roll: ).

Gruß

AHT

AHT - Do 08.11.07 22:20

Chryzler hat folgendes geschrieben:

Bitte auch den Inhalt des Edits posten - fängt ja gut an.
Ob das normal ist, will ich herausfinden - das ist auf jeden Fall nicht überall so.

Chryzler - Do 08.11.07 22:24

Ähm, also das Edit ist schonmal zu klein für den ganzen Text, der eingefügt werden sollte, deswegen ist das jetzt auch nur die Hälfte. Die letze PID wäre 6092 gewesen, der Text geht aber nur bis 2488. :nixweiss: Ich hab mal die Einträge mit den grünen Pfeilen weggelassen.. außerdem die log.txt erst runterladen und dann öffnen, im Browser wirds falsch formatiert.

AHT - Do 08.11.07 22:35

Ich habe nicht mit einer solchen Menge gerechnet - was ich sehe reicht aber. Alles , wo der Exitcode 0 ist, ist schon mal kein RootKit.
Vom HandleCount muss man 1 abziehen, das hat ja mein Testprozess geöffnet. Was mich da besonders irritiert - alle Handles sind ja dicht, bevor mein Prozess eins geöffnet hat - warum ist das Prozessobjekt dann immer noch im Speicher?
Das es wirklich im Speicher ist und hier nicht nur heiße Luft ausgelesen wird, sieht man an den Zugriffsrechten, am ausgelesenen PEB und den Zeiten.
Läuft da in manchem Windows etwas schief oder liegt die Schieflage in meiner Gedankenwelt?

PS: Bitte das ganze Edit posten - ganz oben steht Servicepack und Windowsversion.

Dornathal - Fr 09.11.07 00:01

oO also bei mir ist bald über die hälfte an prozessen blau markiert ....

Bei mir gehts bis 8060... hab jetzt die log.txt nicht nochmal nachgeschaut aber vll fehlt ja was...

AHT - Fr 09.11.07 09:37

Besten Dank, auch hier das gleiche. Prozesse laufen nur wenige Sekunden, sind beendet und haben kein offenes Handle auf den Prozess.
Global Flag steht auf 0, das dürfte also nicht an einer gespeicherten Objektliste liegen. Ich lade nachher mal einige Tests von meinen Rechnern hoch (fast alle ohne blaue PIDs) und ersetze das Edit gegen ein RichEdit - da passt mehr rein.
Wer von euch sieht keine blauen Dreiecke (so wie ich)?
Welches OS und Servicepack benutzen die, die keine blauen Dreiecke sehen? Welche Prozessse laufen dort? Welche Firewall wird verwendet?
Benutzt jemand noch Windows2000 und sieht dort blaue Dreiecke?
Ich habe im Augenblick den Eindruck, das die Startzeiten dieser "Prozesse" immer innerhalb der Zeit eines LogIns liegen - kann das jemand bestätigen?

Gruß

AHT

AHT - Fr 09.11.07 16:45

So, langsam wird es klarer, woran das liegt.
Ich habe jetzt mal ein Update der Testdatei hochgeladen und möchte noch ein paar Leute mit XP Professionell bitten, mir Rückmeldung zu geben. Wenn jemand mit XP Home die blauen Dreiecke nicht sieht, bitte auch noch hier posten.

Gruß

Opa AHT

Chryzler - Fr 09.11.07 16:55

AHT hat folgendes geschrieben:

So, langsam wird es klarer, woran das liegt.

An was? *neugierig* :)

Ich habs jetzt nochmal neu durchlaufen lassen, außerdem hab ich Win XP Professional. Die Anzahl der blauen Dreiecke ist noch relativ niedrig, hab das System auch erst gestartet gehabt.

Sinspin - Fr 09.11.07 17:18

Ich bekomme auch eine große menge an Blauen. (XP Prof)
Mein Rechner läuft jetzt seit rund einer Woche ohne das ich ihn zwischenzeitlich mal richtig neu gestartet habe. Der ist immer nur im Ruhezustand wenn er aus ist. Er macht also fast da weiter wo ich ihn angehalten habe.
Somit ist noch alles im Ram wozu Windows keine Luste hatte es frei zu geben. Und genau danach sieht es aus. es wird einfach die prozesstabelle erweitert, anstatt alte einträge zu überschreiben. (vieleicht ist das der Grund warum der manchmal nach rund zwei Monaten anfängt komische Sachen zu machen).

AHT - Fr 09.11.07 20:36

Ich bin im Augenblick etwas in "Opastress" werde da aber noch weiter schauen.
Ich hatte erst die Vermutung, dass das an XP Home liegt - das ist aber nicht der Fall.
Wo keine blauen Dreiecke zu sehen sind, erscheinen später auch keine.
Wo blaue Dreicke zu sehen sind, wird scheinbar jeder beendete Prozess zu einem blauen Dreieck.

Ich werde mir demnächst mal die Liste der laufenden Programme anschauen - vielleicht finde ich da irgendwelche Übereinstimmungen.

Wer sieht, außer mir, auch keine blauen Dreiecke?

AHT - Fr 09.11.07 20:44

Hier noch ein paar Beispiele...

Ich hatte schon den Verdacht, dass das am Netzwerk und der XP Firewall liegt - dem ist aber scheinbar nicht so. Zum Test habe ich mal bei mir auf Lappi00 Netzwerk und Firewall installiert - ebenfall keine blauen Dreiecke zu sehen.

Gibt es hier irgendwo im Forum die Möglichkeit, mal eine Umfrage zu starten, wieviele Leute genau keine blauen Dreiecke sehen???

Wolle92 - Fr 09.11.07 20:56

Hmmm...
Also ich hab Windoof Vista, da gibts keine blauen Dreiecke... Mit Netzwerk und Firewall... nix...
Habs auch mal als Admin ausgeführt, auch keine...

AHT - Sa 10.11.07 13:26

Danke für die Rückmeldung, von Vista weiß ich darüber noch gar nichts.

Nochmals Zusammenfassung: Unter XP werden aus irgendeinem Grund auf manchen Systemen die PIDs schon beendeter Prozesse (und Threads, die Teste ich mit dem Programm aber nicht) nicht wieder freigegeben, obwohl kein Handle auf diese beendeten Prozesse offen ist. Auch im Usermode auslesbare Prozessdaten werden nicht gelöscht, was eigentlich nur bedeuten kann, dass Speicher nicht wieder freigegeben wird.

Was kann das bedeuten:
- Wo Speicher nicht wieder freigegeben wird, wird (auch wenn es sich um wenig Speicher handelt) der reale Speicherverbrauch im Laufe der Zeit immer größer und es kommt evtl. zu Problemen.
- Wo es darum geht, auf Low-Level ebene den Speicher auszulesen, kommt es auf unterschiedlichen Geräten mit dem gleichen OS zu unterschiedlichen und irreführenden Ergebnissen (da liegt mein Problem mit der Sache).

Und nochmal:
Wer unter XP sieht diese blauen Dreiecke nicht?
Gibt es hier in diesem Forum eine Möglichkeit, dazu eine Umfrage (zum Ankreuzen) zu erstellen? In manchen Foren geht das...

Chryzler - Sa 10.11.07 13:53

Es scheint so, als würden nur manche Programme diese "PID-Leichen" erzeugen. Notepad erzeugt immer welche, der Ping-Befehl aber anscheinend nicht. Vielleicht bleiben nur die PIDs von Programmen im Speicher, die ein (sichtbares?) Fenster haben, ober halt keine Konsolenanwendung sind.

Wenn man sehr viele Programme startet, dann zwingt das Windows theoretisch dazu, für neue Anwendungen immer höhere PIDs zu vergeben, auch wenn die alten schon längst beendet wurden. Hatte gerade 100 Mal Notepad gestartet, und Windows vergibt jetzt bei neuen Prozessen PIDs im 4-stelligen Bereich.

AHT - Sa 10.11.07 15:49

Chryzler hat folgendes geschrieben:

Besten Dank für die Rückmeldung! Wenn das wirklich nur bei Prozessen auftritt die ein Fenster haben, ist da evtl. ein Fenster-Hook aktiv, der da Probleme macht. Im Anhang befindet sich ein Testprogramm, das sich mit SetWindowsHookEx nit hooken lässt und keine Fenster hat. Kannst du mal schauen, ob diese PID nach dem Beenden über den Taskmanager ebenfalls noch blau sichtbar ist?

Gruß

AHT

Chryzler - Sa 10.11.07 16:09

Okay..

keine blauen Dreiecke bei der test.exe. Was übrigens extrem hilfreich wäre, wenn du in das Analysierungsprogramm eine kleine Anzeige einbauen könntest, wieviele blauen Dreiecke gefunden wurden.

AHT - Sa 10.11.07 16:13

Chryzler hat folgendes geschrieben:

Das könnte also ein über SetWindowsHookEx aufgerufener Hook sein, der dort die Prozesse nicht richtig sterben lässt. Ich schaue da nochmal etwas genauer nach...

Gruß

AHT

AHT - Sa 10.11.07 16:16

Zum Programm werde ich noch eine Statusbar hinzufügen, die die Anzahl der sichtbaren Prozesse und der blauen PISs anzeigt.

Gruß

AHT

AHT - Sa 10.11.07 17:35

OK, Statusbar hinzugefügt und Update Programmes hochgeladen.
Die Statusbar zeigt nun an, wie viele sichtbare Prozesse gefunden wurden, wie viele blaue PIDs gefunden wurden und ob evtl. einer der blauen PIDs zu einem RootKit gehört.

Versuche, gleich mal nach den Hooks zu schauen. Muss noch warten, bis der passende PC mit dem Fehler frei ist.

Gruß

AHT

AHT - Sa 10.11.07 18:46

So... Habe mal alle Hooks auf die ich Zugriff hatte mit einem Programm von mir entfernt - kein Erfolg, der Fehler tritt immer noch auf.
Was mir aber aufgefallen ist:
Bear ( http://www.geocities.com/the_real_sz/misc/Bear.zip )
zeigt mir an, das CSRSS.EXE ein Handle auf einen Hook geöffnet hat. Das zeigt es mir aber bislang nur auf dem Gerät an, das den Fehler produziert! Auf allen anderen Geräten mit XP hat CSRSS.EXE kein Handle auf einen Hook geöffnet!!! Bitte, bitte mal testen - was sagt Bear auf anderen Geräten? Hat CSRSS.EXE ein Handle auf einen Hook geöffnet? Und was sagt dabei mein Prozesshandle Test? Sind blaue Dreiecke zu sehen?

Evtl. liegt da eine Macke in WindowsXP selbst vor, die sich nur unter ganz bestimmten Voraussetzungen (einem bestimmten Betriebssystem-Update) zeigt?

Gruß

AHT

Chryzler - Sa 10.11.07 18:52

Bei csrss.exe und Hook steht bei mir mal 2 dran. explorer.exe hat ganz viele Hooks, und viele andere Programme auch.

AHT - Sa 10.11.07 19:02

Chryzler hat folgendes geschrieben:

Bei csrss.exe und Hook steht bei mir mal 2 dran.

Jetzt wirds interessant, da könnte der Grund liegen!

Zeigt irgendwo Bear bei CSRSS.EXE kein Handle auf einen Hook an aber der Prozesshandle Test blaue Dreiecke?

Zeigt irgendwo Bear bei CSRSS.EXE ein Handle auf einen Hook an aber der Prozesshandle Test keine blauen Dreiecke?

Kann irgendjemand meine Vermutung bestätigen, dass das an den Hooks von CSRSS.EXE liegen könnte?

Chryzler hat folgendes geschrieben:

explorer.exe hat ganz viele Hooks, und viele andere Programme auch.

An den anderen Anwendungen, einschließlich dem Explorer, liegt das nicht. Die habe ich überprüft.

Gruß

AHT

GTA-Place - So 11.11.07 10:07

Hier noch meine Werte:

- Windows XP Home
- kein blaues Dreieck
- CSRSS.exe hat kein Handle auf einen Hook

hansa - So 11.11.07 10:28
Titel: Re: Merkwürdigkeiten in Windows (XP)

XP pro SP2. Bei mir kommen ein paar blaue Dreiecke. Prozessname und Dateiname sind dabei leer. Dann noch ein Haufen grüne Dreiecke.

Aber wieso das :

AHT hat folgendes geschrieben:

(Scan dauert ein paar Sekunden).

Könnte wohl wesentlich schneller gehen. Kenne den Effekt zwar nur vom Stringrid, aber dürfte hier ähnlich sein. Die Listview wird offensichtlich gezwungen, sich andauernd neu zu zeichnen (kostet Faktor 10-100). So was merkt man. Setze mal visible auf false und erst dann auf true, wenn das Ergebnis feststeht.

AHT - So 11.11.07 10:45
Titel: Re: Merkwürdigkeiten in Windows (XP)

hansa hat folgendes geschrieben:

XP pro SP2. Bei mir kommen ein paar blaue Dreiecke. Prozessname und Dateiname sind dabei leer. Dann noch ein Haufen grüne Dreiecke.

Aber wieso das :

AHT hat folgendes geschrieben:

(Scan dauert ein paar Sekunden).

Biite nochmals testen. Habe gerade eine neue Version hochgeladen, diese Version zeigt nun auch die Anzahl der von jedem Prozess geöffneten Hooks an:
http://freenet-homepage.de/ahfundgrube/PH.zip

Wichtig ist für mich, ob CSRSS.EXE einen Hook öffnet. Deswegen bitte den Inhalt des Edits mit WordPad in eine Datei kopieren und dann hier posten. Ich vermute im Augenblick einen Fehler im Subsystem von Windows, der evtl. bei bestimmten grafischen Einstellungen auftritt.

Das der Scan so lange dauert, liegt an der von mir hier verwendeten Programmiersprache - ist mir im Augenblick auch egal, wichtig ist das Ergebnis (ob der Bug in Windows liegt oder nicht). Mit dem Listview hast du natürlich ebenfalls Recht.

Gruß

AHT

GTA-Place - So 11.11.07 12:17

So, nach einer Weile zocken und arbeiten, habe ich 10 blaue Dreiecke und 1 mögl. Rootkit.

AHT - So 11.11.07 12:46

GTA-Place hat folgendes geschrieben:

So, nach einer Weile zocken und arbeiten, habe ich 10 blaue Dreiecke und 1 mögl. Rootkit.

Ein RootKit läuft bei dir nicht ( -1 hatte ich bislang noch nicht :) ). Das ist nur ein Hinweis für mich bei Rückmeldungen da mal etwas näher nachzuschauen.
Das nach längerem Arbeiten mehere blaue PIDs erscheinen wenn bei dir das Phänomen auftritt, ist klar. Jeder Prozess mit einem Fenster wird nach dem Beenden zu einer blauen PID.

An dem Hook im Subsystem scheint das ebenfalls nicht zu liegen, der ist bei dir nicht vorhanden.
Bin im Augenblick ratlos und lege die Sache erst einmal zu den Akten. Vielleicht komme ich später nochmal auf Ideen.

Gruß

AHT

Chryzler - So 11.11.07 16:01

Ich hab 16 Rootkits auf meinem System. :mrgreen:

AHT - So 11.11.07 16:19

Chryzler hat folgendes geschrieben:

Ich hab 16 Rootkits auf meinem System. :mrgreen:

:mrgreen: Wie gesagt, das sind keine RootKits. Ich kontrolliere da nur den ExitCode, und wenn der nicht 0 ist, wollte ich etwas genauer nachsehen, woran das liegt :rofl:.
Bei mir habe ich das Problem mit den blauen Dreiecken ja nicht; und ich bin, weil die Programme ja in der Regel normal beendet wurden davon ausgegangen, dass der Exitcode bei den Prozessleichen immer 0 ist. Da die einfachen RootKits, die für mein Programm sichtbar sind, in der Regel den Exitcode nicht ändern, wäre ein sichtbarer Pfad und ein Exitcode mit 259 ein recht guter Hinweis auf ein laufendes RootKit (kann natürlich aber auch andere Ursachen haben). Ich werde mal den Hinweis in der Statusbar abändern - ist doch zu Haarsträubend :mrgreen:.

PS: Macke beseitigt, Update hochgeladen (Aua ). Vielleicht war ich da doch etwas zu übervorsichtig... :gruebel:

Gruß

AHT

AHT - So 25.11.07 18:28

Da mir immer noch ein Überblick fehlt, wie oft diese "Merkwürdigkeit" unter XP auftritt, habe ich hier
http://forum.freenet.de/app/m/_t250172c169pf6168849computer_Bitte_um_Test_Merkwuerdigkeiten_in_Windows_XP__ProgrammierEcke_Computer.html
mal eine Umfrage veröffentlicht. Um daran teilnehmen zu können, muss man sich kostenlos bei der Freenet-Community registrieren lassen. 60MB werbefreien Homepageplatz und eine kostenlose E-Mail Adresse gibt es dann von Freenet für diese "Unannehmlichkeit" kostenlos dazu...

Sinspin - So 25.11.07 19:11

Glaubst du, das du dort vernünftige Antworten bekommst? Ich war dort früher mal recht fleißig in der Programmierer Sektion am Lesen und Posten. Die Fragen und Antworten der User waren aber zum sehr großen Teil unterkannte Bodenplatte.
Und du suchst ja doch eher Hinweise darauf woran es liegen könnte das bei machen Rechnern ein haufen tote Prozesse angezeigt werden und bei anderen nicht.
Ich kenne zwar einige Leute die versuchen werden dich dort zu unterstützen. Aber der Rest :gruebel:

AHT - So 25.11.07 19:42

Sinspin hat folgendes geschrieben:

Glaubst du, das du dort vernünftige Antworten bekommst?

Nein, vernünftige Anworten habe ich schon hier bekommen (nochmals besten Dank dafür an alle).
Bei mir laufen nur Rechner mit einem extrem Abgespecktem XP - ich habe im Augenblick also keine Ahnung, ob dies "Merkwürdigkeir" vielleicht der Regelfall ist und nicht die Ausnahme. Ich hofe, dass mir eine Umfrage dabei helfen wird, das etwas genauer zu beurteilen. Ob ich dört überhaupt irhendwelche Rückmeldungen bekomme, steht auf einem ganz anderen Blatt.

Evtl. komme ich nicht dahinter, was genau Prozesse mit einem Fenster auf manchen XP Systemen nicht richtig sterben lässt (was unter anderem zum unaufhörlichen Ansteigen der PIDs führt) - aber eine "etwa" Vorstellung, ob das die Ausnahme oder der Regelfall ist, hatte schon gerne.

TProgger - So 25.11.07 20:40

Hab das bei mir auch mal laufen lassen. Siehe Anhang.

AHT - So 25.11.07 21:27

Mmmh...

Das was da rumzickt scheint sich schon vor CSRSS.EXE zu starten, ist also scheinbar eine Komponente des Betriebssystems oder ein Treiber.

Delete - So 25.11.07 22:03

AHT hat folgendes geschrieben:

wäre ein sichtbarer Pfad und ein Exitcode mit 259 ein recht guter Hinweis auf ein laufendes

Öhm, der ExitCode sagt gar nicht aus. Den kann jeder Programmierer beliebig setzen, wie ihm lustig ist. Konsolenprogramme nutzen ihn manchmal, um dem aufrufenden Programm mitzuteiln, ob ein Fehler aufgetreten ist oder nicht.

AHT - So 25.11.07 23:48

Luckie hat folgendes geschrieben:

AHT hat folgendes geschrieben:

wäre ein sichtbarer Pfad und ein Exitcode mit 259 ein recht guter Hinweis auf ein laufendes

Das ist richtig - mit TerminateProcess oder WriteProcessMemory zum Beispiel, das Programm scannt ja auch nicht nach RootKits. Ein Exitcode von 259 kennzeichnet aber einen laufenden Prozess. Ein ProcessHider oder ein RootKit, das so einfach gestricktes ist, das dieser Test es blau anzeigt, wird wohl kaum über WriteProcessMemory und Native-API den ExitCode ändern. Ein Exitcode von 259 wäre also ein recht guter Hinweis für mich, dass dieses spezielle blaue Dreieck auf keinen Fall durch das hier beschriebene Phänomen sondern eventuell durch einen sehr einfachen ProcessHider erzeugt wurde und ein recht guter Hinweis für den Tester, sein System vielleicht mal (mit RootKit Unhooker) auf RootKits zu scannen. Dass ein ExitCode von 259 nicht unbedingt von einem RootKit stammen muss, steht außer Frage - es geht hier auch nicht um RootKits, sondern um "Prozessleichen".

Delete - So 25.11.07 23:57

Du solltest eventuell das nächste mal etwas klarer sagen, um was es dir eigentlich geht, anstatt von grünen und blauen Dreiecken zu reden. Hättest du das getan, dann hätte ich gleich gewusst, um was es geht. Das läuft im Allgemeinen unter der Bezeichnung "Zombie Prozesse", such da nach mal mit Google.

AHT - Fr 30.11.07 20:45

Luckie hat folgendes geschrieben:

Besten Dank, das trifft es (glaube ich) ziemlich gut.
http://de.wikipedia.org/wiki/Zombie_(EDV)
Jetzt fragt sich nur noch, ob diese "Zombieprozesse" nach dem Beenden und Neustart des WindowsExploreres (der dürfte ihn der Regel der Vater sein) verschwinden. Wenn dem so ist und nur die PID des alten WindowsExplorers als "Zombie" übrig bleibt, dürfte der WindowsExplorer selbst dieses Problem verursachen - sehe ich das richtig?

Es wäre demnach ja auch noch wichtig, beim Auftreten solcher "Macken" den Elterprozess mit auszulesen. Das dürfte machbar sein - werde mal ein Update schreiben.

Besten Dank

AHT

AHT - Fr 30.11.07 23:09

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.

Delete - Sa 01.12.07 00:59

AHT hat folgendes geschrieben:

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

Wie hast du das gemacht?

Zyklame - Sa 01.12.07 01:36

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

teamrocket0 - Sa 01.12.07 01:52

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?

AHT - So 30.12.07 17:44

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.

AHT - So 30.12.07 17:48

Zyklame hat folgendes geschrieben:

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.

AHT - So 30.12.07 18:03

teamrocket0 hat folgendes geschrieben:

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.

AHT - So 30.12.07 18:45

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.

Chryzler - So 30.12.07 18:56

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?

AHT - So 30.12.07 19:54

Chryzler hat folgendes geschrieben:

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.

AHT - Mo 28.01.08 18:17

Da ich mir demnächst bei Gelegenheit die Treiber nochmals etwas näher betrachten möchte, habe ich noch ein Update des Testprogramms erstellt:
http://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

AHT - So 03.02.08 16:19

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 [http://freenet-homepage.de/ahfundgrube/PH.zip] 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?

alias5000 - So 03.02.08 17:05

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

Gruß
alias5000

AHT - So 03.02.08 17:09

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.

Martok - So 03.02.08 18:30

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

AHT - So 03.02.08 18:36

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

Chryzler - So 03.02.08 20:54

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.

AHT - So 03.02.08 22:13

Chryzler hat folgendes geschrieben:

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.

alias5000 - So 03.02.08 22:29

Dann schreib denen doch ne Mail ;)

AHT - So 03.02.08 22:31

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.

Tilo - So 03.02.08 23:46

Danke AHT,
jetzt weiß ich was meinen Rechner so lahm macht nach 3 Wochen dauer on.
Da mir das Starten von Windows zu lange dauert nutze ich den Ruhezustand. Dadurch sind die Zeiten dann halt etwas lang.
Bei diesem Bilchen im Nahang ist der letzte Restart 12 Tage her.
Nochmals Vielen Dank.

AHT - So 03.02.08 23:57

Jau, da ist er wieder - AntivVir :).
Habe meine Ergebnisse erst einmal ins AntiVir Supportforum [http://forum.avira.com/thread.php?threadid=33338] gestellt - eine Support-Mail finde ich im Augenblick nicht.

An alle, die noch zu dem Thema was sagen wollen: Bitte auch die LOGs hier als Anhang posten. Einfach mittels Rechtsklick in Wordpad kopieren oder die durch Rechtsklick ins Edit erstellbare RTF-Datei nutzen.

AHT - Di 05.02.08 09:10

Vorausgesetzt ich habe recht mit meinen hier gemachten Aussagen (bitte diesbezüglich noch einige Leute mal zu testen und dies damit zu belegen oder zu wiederlegen), hier mal meine Vermutung, also etwas "Brainstorming", wie es zu dem Fehler kommen könnte:

Es gibt da eine schöne Funktion: PsSetCreateProcessNotifyRoutine aus der ntoskrnl.exe, ist also eine Kernelmode Funktion.
Diese Funktion Funktion installiert einen Callback, der immer dann aufgerufen wird, wenn ein Prozess gestartet oder beendet wurde.
Sinnvoll wäre es, diese API in die DriverEntry Struktur eines Treibers einzubauen.
Scannt man im Kernel gerade nach RootKits und durchsucht Speicher, wäre es ganz ungünstig, wenn gerade in diesem Augenblick ein Prozess beendet würde und genau die Objektdaten, die man gerade ausliest, im Nirwana verschwinden (=> BSOD). Was macht man also? Man hält die Objekte solange (?vielleicht mit ReferenceObject?) im Speicher, wie diese benötigt werden und gibt diese erst wieder frei, wenn man den besagten Speicher nicht mehr ausliest. Die Freigabe kann also nicht sofort nach dem beenden des Prozesses erfolgen. Bloß - wann genau gibt man den (mit ?DereferenceObject?) wieder frei, damit es wirklicht nicht crasht?.....

Sinspin - Di 05.02.08 13:31

Ich habe in den Antivir Programmen auch schon ettliche Fehler, bzw. deutliche Mängel in der Software gefunden die ich gerne den AV-lern mitgeteilt hätte.
Aber! Zum einen gibt es nicht wirklich Kontaktmöglichkeiten, und zum anderen, bekommt man NIEMALS eine Antwort. Da ich bei denen Kunde bin, finde ich das umso bedauerlicher.

Einen Versuch ist es aber trotzdem Wert.

AHT - Di 05.02.08 13:36

Sinspin hat folgendes geschrieben:

Dein LOG hätte ich gerne; ich glaube, das fehlt mir noch. Das ganze scheint Hardwareabhängig zu sein. Bei zwei Leuten mit IBM Thinkpads scheint der Fehler nicht aufzutreten. Bei den Problemen, von denen du da sprichst, bin ich deiner Meinung.

FiceGoesDelphi - Di 05.02.08 16:35

Jetzt bin ich auch mal neugierig geworden!
Ich werde heute Abend wenn ich zu Hause bin auch mal diesen Test machen und "was auch immer" hochladen ;)

AHT - Mi 06.02.08 10:00

Tilo hat folgendes geschrieben:

Danke AHT,
jetzt weiß ich was meinen Rechner so lahm macht nach 3 Wochen dauer on.

Ich habe die Sache mal ausgetestet, da es mich doch sehr interessiert hat, was diese Zombies überhaupt für Auswirkungen haben.

- Jeder Zombie verbraucht etwas Speicher, das heißt, irgnwann wird immer mehr virtueller Speicher auf die Festplatte ausgelagert und immer weniger nutzvolle Sachen stehen wirklich im RAM (Rechner wird langsam).

- Bei kleineren Festplatten reicht sehr schnell die Auslagerungsdatei nicht mehr aus und muss vergrößert werden. Solange diese nicht vergrößert wird, können keine neuen Prozesse gestartet werden.

- Windows bekommt bei einem sehr lange laufenden Rechner nach einiger Zeit (eigentlich recht schnell) eine Auslagerungadatei von über 2GB Größe, obwohl eigentlich gar keine Anwendungen laufen (SinSpin und BlackDragon sollten sich mal diesbezüglich ihre Rechner ansehen - da ist scheinbar genau das der Fall).

- Ein weiteres Problem liegt in den PIDs, die nicht unbegrenzt zu Verfügung stehen - aber das ist wohl das kleinste Problem.

Man merkt kaum etwas oder gar nichts von diesen ganzen Sachen, wenn man am Ende eines Tages den Rechner herunterfährt und am nächsten neu startet. Muss der Rechner aber Wochen oder Monatelang durchlaufen, gibts es irgendwann ganz ganz heftige Probleme. Bei meinem kleinen alten Noti (mit dem ich das hier schreibe) rechten 1500 PIDs aus, damit gar nichts mehr ging.

Bitte hier SinSpin und BlackDragon nochmal um LOGs.

PS: Wo steckt FiceGoesDelphi? Kann auch LOGs gebrauchen, bei denen der Rechner zwar mit AntiVir läuft, aber keine Zombies produziert. Das scheint vor allem bei IBM ThinkPads der Fall zu sein. Es spielt da also wohl scheinbar eine zweite Komponete (ein Hardwaretreiber) eine Rolle.

FiceGoesDelphi - Mi 06.02.08 10:07

Habs vergessen :oops:
War so in ein paar Aufgaben vertieft, dass ich es total vergessen hatte *seufz*
Kannst du mir nicht eine "ErinnerungsPN" schicken? :D So heute Abend ggn 18 Uhr *gg*
Ich hab nen Win Prof mit AntiVir Rechner zu Hause ;)

Sinspin - Mi 06.02.08 17:43

Hm ja! Wollte ich gestern Abend machen. Aber aus Abend ist dann Heute früh um Zwei geworden und ich habe nicht mehr dran gedacht.
Bei mir kommen Ergebnisse von drei Rechnen zusammen. Davon laufen zwei jetzt fast einen Monat. Und vor ein paar Tagen hatte einer bei einem Test mit deinem Programm deutlich über 1000 PID's auf dem Buckel.
Wenn ich heute Abend dran denke, hoffentlich 5 Stunden eher als Gestern, gibt es alle drei Logs auf einmal.

Sinspin - Do 07.02.08 02:14

So, nun auch meine Logs.
2K01zombie.txt
- Win2000
- läuft seit knapp 14 tagen ununterbrochen
- wird regelmäßig verwendet
- keine Auffälligkeiten

XP01zombie.txt
- WinXP
- läuft seit gut zwei wochen (jeden Abend in den Ruhezustand gebracht)
- wird jeden tag verwendet
- deutlich auffällig

XP02zombie.txt
- WinXP
- läuft seit rund 4 tagen ununterbrochen
- wird nahezu nicht verwendet
- kaum auffällig

FiceGoesDelphi - Do 07.02.08 20:21

So, ob und wann ich meine m8s dazu bekomme das auch zu machen weiß ich nicht!

Hier meins!
In der Anzeige sehe ich nur 1 Blaues ^^

AHT - Fr 08.02.08 08:37

FiceGoesDelphi hat folgendes geschrieben:

So, ob und wann ich meine m8s dazu bekomme das auch zu machen weiß ich nicht!

Hier meins!
In der Anzeige sehe ich nur 1 Blaues ^^

Bei dir tritt dieser Fehler nicht auf. Der Zombie auf deinem Rechner hat einen Handlecount von 2 - das bedeutet, er ist mit großer wahrscheinlichkeit durch ein nicht geschlossenes Handle im Usermode verursacht worden. Der Treiber avipbb.sys, der Ursache dieses Fehlers ist, wird bei dir aus irgendeinem Grund gar nicht geladen!

FiceGoesDelphi - Fr 08.02.08 10:02

AHT hat folgendes geschrieben:

FiceGoesDelphi hat folgendes geschrieben:

So, ob und wann ich meine m8s dazu bekomme das auch zu machen weiß ich nicht!

Hier meins!
In der Anzeige sehe ich nur 1 Blaues ^^

Und jetzt bitte nochmal auf Deutsch :>

AHT - Fr 08.02.08 10:39

FiceGoesDelphi hat folgendes geschrieben:

Und jetzt bitte nochmal auf Deutsch :>

Zu erst einmal wird bei dir der AntiVir Treiber avipbb.sys für den RootKit Scanner gar nicht geladen - evtl. hat Avira bereits aufgrund meiner Meldung ein Bugfix herausgebracht und der besagt Treiber wird gar nicht mehr immer geladen - ich kann das aber zu Zeit nicht testen, da ich nicht mit XP im Netz hänge.

Der Zombie bei dir hat einen Handlecount von 2 - das bedeutet, es wurden zwei Handles auf diese PID geöffnet (siehe API OpenProcess).

Solange ein Objekt irgendwie referenziert ist - Windows also denkt, es ist noch in Gebrauch, wird es nicht gelöscht. Die Objekte, um das es hier geht, sind Prozesse. Referenzieren kann man einen Prozess, indem man mit OpenProcess ein Handle auf diesen Prozess öffnet. Der Handlecount, also die Anzahl der Handles auf diesen Zombie, ist 2. Ein Handle hat mein Programm geöffnet, um die Daten über den beendeten Prozess auszulesen (das musst du immer abziehen) - ein Handle wurde (wahrscheinlich) von "jemand anderem" geöffnet, bevor der Prozess beendet wurde.
In diesem Fall hat dieser "Jemand" geschlampt und das Handle noch nicht geschlossen, obwohl der Prozess nicht mehr existiert => Fazit: Das Objekt (also die Daten über den Prozess) kann nicht gelöscht werden, da es noch über das Handle in Gebrauch ist.

OpenProcess ist ein API, die in normalern Programmen verwendet werden kann - also eine "Usermode-API". In einem Treiber gibt es andere Möglichkeiten, ein Objekt vor der Löschung zu bewahren, ohne ein Handle darauf zu öffnen - ReferenceObject zum Beispiel.

Ich möchte hier aber betonen, dass ich beim besten Willen kein Experte in Sachen Treiber bin und bislang noch recht wenig von diesen Dingern geschrieben habe (zwei bislang). Einen Treiber musst du dir unter NT-basierenden Windowssystemen (NT/2000/XP/Vista) wie eine Art DLL vorstellen, die in Speicherbereiche geladen wird, auf die ein normales Programm keinen Zugriff hat - diese also weder auslesen noch beschreiben kann. Diese "DLLs" (in der Regel mit der Endung .SYS) werden vom Prozess "System" geladen, das Prozesserzeugende Modul dieses Prozesses ist ntoskrnl.exe bzw. ntkrnlpa.exe
.
Ich hoffe, dass ist so einigermaßen verständlich - oder was möchtest du wissen?

FiceGoesDelphi - Fr 08.02.08 12:15

Ok, so weit verstanden.
Vielen Dank!

Im Grunde genommen geht es meinem Baby (PC^^) also ganz gut, oder? ;)
Das ist das wichtigste :>

AHT - Fr 08.02.08 16:20

FiceGoesDelphi hat folgendes geschrieben:

Ok, so weit verstanden.
Vielen Dank!

Im Grunde genommen geht es meinem Baby (PC^^) also ganz gut, oder? ;)
Das ist das wichtigste :>

Ja, dem geht es sehr gut.

AHT - Sa 09.02.08 10:01

Habe noch ein Update des Testprogramms hochgeladen. Ist ein Zombie durch ein geöffnetes Handle auf einen Prozess erzeugt worden (ist also der Handlecount größer als 1), kann nun optional nach dem Verursacher gesucht werden, der das Handle geöffnet hat.

PS: Im Anhang auch noch mal was nettes zum drüber Lachen oder lächeln.

AHT - Di 12.02.08 18:44

Das dürfte für andere Programmierer interessant sein, deshalb schreibe ich das hier mal hin:
Der Usermodespeicher wird scheinbar bis auf eine eine Speicherseite (=4KB) komplett wieder freigegeben; zum freigegebenen Bereich gehört auch der Adressbereich des PEB. Der Rest, der an Speicher verpulvert wird, scheint sich im Kernel zu befinden. Die Objekte, die dort nicht gelöscht werden, sind neben Process auch auf jeden Fall auch Token und Thread.

Die Bugmeldung wurde scheinbar an Avira weitergeleitet und ich rechne damit, dass es zu einem Bugfix kommt. Meine XP Rechner hängen alle nicht im Netz und können keine Updates von AntiVir ziehen. Wenn jemand also merkt, dass in einer neueren Version von AntiVir dieses Problem nicht mehr besteht, bitte ich hier um Rückmeldung.

Besten Dank und Gruß

AHT

Sinspin - Di 12.02.08 19:58

Passt du den PID Bereich den du untersuchst dynamisch an oder scannst du immer nur bis zur 16000?
Meine aktuell letze gescannte ist die 15980!
Interessant ist, das die Zombie.exe jetzt keine PID bekommen hat die größer als 15980 war, sondern die 15068.
Das könnte darauf hindeuten das Windows PID's die korrekt freigegeben wurden wieder verwendet.
Nur wundert es mich dann warum die Zombies mit ihren PID's manchmal ziemlich weit auseinander liegen.

AHT - Di 12.02.08 20:23

Sinspin hat folgendes geschrieben:

Nein, scanne dynamisch bis 65536. Windows belegt die PIDs scheinbar nicht kontinuierlich nacheinander, sondern es gibt immer zwischendurch kleinere Lücken, die später aufgefüllt werden. Außerdem werden Prozesse ohne eigenes Fenster ja korrekt gelöscht - diese Lücken belegt Windows ebenfalls später noch.

AHT - Mi 20.02.08 16:36

Da scheint noch jemand auf das gleiche Problem gestoßen zu sein. Lustig, wie sich manche Sachen gleichen... :roll:

http://kay-bruns.de/wp/2007/10/11/stockschirm/

uall@ogc - Mi 05.03.08 13:08

Hi hab den Thread erst jetzt gesehen.
Die Prozesse sind jedenfalls noch in der EProcess liste drin, sagt jedenfalls mein FireShield. IceSword und andere Programme zeigen das aber gar nicht an.

Vielleicht schau ich mir den Treiber mal genauer an von Antivir, benutzt das ja auch :)

AHT - Mi 05.03.08 14:18

uall@ogc hat folgendes geschrieben:

Vielleicht schau ich mir den Treiber mal genauer an von Antivir, benutzt das ja auch :)

Das wäre klasse! Ich habe von Reverse Engineering einfach zu wenig Ahnung und nur mal kurz drüber gesehen, was mich zu der Meinung gebracht hat, das meine Vermutung mit ObReferenceObject (und "Konsorten") und PsSetCreateProcessNotifyRoutine wohl so ziemlich trifft.

Bin gespannt, ob die da evtl. ein Update rausbringen und würde mich freuen (falls du zu Erbenissen kommst und überhaupt Zeit dafür hast), wenn du im Avira Forum unter meinen Thread eine Antwort posten würdest:
http://forum.avira.com/thread.php?threadid=33338

Es wird bestimmt dauern, bis Avira für den Treiber ein Update bringt, die haben sich mit Vista ja schon genug in die Nesseln gesetzt und wollen das bestimmt nicht wiederholen.

AHT - Mi 05.03.08 16:07

Ah... Habe mir grad dein Tool angesehen und weiß jetzt, was du meinst. Da sind Kernelmode Hooks auf eine scheinbar etwas merkwürdig Adresse.

Das ist dein Spezialgebiet und ich bin wirklich gespannt, was du da herausfindest...

uall@ogc - Mi 05.03.08 18:53

die Kernelhooks sind allerdings nicht von Avira (denk ich zumindest)
ich meinte eher die EProcessliste in der die Zombis angezeigt werden

Debuggen kann ich im mom net da mein Rechner putt ist auf dem SoftIce drauf war
aber ich kann jetzt Zombies reproduzieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:

program nothing2;
 
uses
  windows, shellapi, sysutils;
 
{
  @1: Zombie wird erstellt, wenn avipbb.sys geladen
  @2: Zombie wird nicht erstellt, wenn avipbb.sys geladen
}
 
var
  pHandle: DWord;
begin
  if (ParamCount = 0) then
  begin
    ShellExecute(0,nil,PChar(ExtractFileName(ParamStr(0))),PChar(IntToStr(GetCurrentProcessID)),nil,0); {@1}
    //ShellExecute(0,nil,PChar(ParamStr(0)),PChar(IntToStr(GetCurrentProcessID)),nil,0); {@2}
  end else
  begin
    Sleep(500);
    pHandle := OpenProcess(PROCESS_ALL_ACCESS,false,StrToIntDef(ParamStr(1),0));
    if (pHandle <> 0) then
    begin
      MessageBoxA(0,PChar('Zombie wurde erzeugt, PID: '+ParamStr(1)),'Info',0);
      CloseHandle(pHandle);
    end else
      MessageBoxA(0,'Zombie konnte nicht erzeugt werden. System in Ordnung.','Info',0);
  end;
end.

Mit MicroAngelo ist das aber normal, da es nicht sauber programmiert ist und das Handle auf den Prozess nicht geschlossen wird. Dadurch lässt Windows dieses offen bis MicroAngelo selbst geschlossen wurde und somit das Handle nicht mehr referenziert wird.

Wenn aus Winrar oder Winzip eine Datei gestartet wird und WinZip/Rar geschlossen wird BEVOR das gestartete Programm beendet wurde dann ersteht ein Zombie. Mit obigen Code hab ich das mal nachgebaut. Glaub aber WinRar startet es direkt mit CreateProcess und erstellt vorher ein paar Events, könnte daran liegen. Ich schau mir das aber nochmal genauer morgen an.

AHT - Do 06.03.08 20:02

uall@ogc hat folgendes geschrieben:

die Kernelhooks sind allerdings nicht von Avira (denk ich zumindest)
ich meinte eher die EProcessliste in der die Zombis angezeigt werden

Irrrtum. AVIPBB.SYS scheint folgende Kernelmodefunktionen zu hooken (wenn AVIPBB.SYS nicht geladen ist und auch sonst keine Firewall installieret ist, fehlen diese Hooks):

NtCreateThread
NtOpenProcess
NtOpenThread
NtTerminateProcess

Die neuen Adressen verweisen alle auf Code, der nicht in einem geladenen Modul (Treiber) liegt, also "unsichtbar" ist. Installiert hier AVIRA evtl. selbst ein RootKit????? Das wird ja immer verrückter hier! :shock: ....

Irgendwie funktioniert die EPROCESS Liste bei mir - glaube ich - nicht, da steht bei mir gar nichts drin. Über einen Screenshot würde ich mich da sehr freuen.

uall@ogc hat folgendes geschrieben:

Vollkommen richtig, genau das wollte ich damit sagen - MIKE ist nicht sauber programmiert. Das hat nichts mit dieser Sache zu tun, richtig!

Deinen Code schaue ich mir noch an und werde versuchen, das in meine Programmiersprache umzusetzen.

AHT - Do 06.03.08 20:15

Stop mal!

Da fehlt ja dann eigentlich ein Hook auf NtTerminateThread!!!
Könnte das evtl. erklären, warum nur Zombies entstehen, wenn der jeweilige Prozess ein Fenster hat!
:shock:

uall@ogc - Do 06.03.08 21:02

hab gar nicht auf die hooks geachtet
du schreibst, wenn der treiber nicht geladen ist, dann sind die hooks nicht installiert -> dann ist es von der sys
was ich meinte ist die eprocessliste wo die processe drin stehen (alle die nicht richtig entladen wurden haben keinen pfadnamen)

Und ja TerminateThread sollte eigentlich auch gehookt werden, ist es nicht. CreateProcess(Ex) wird wohl nicht gehookt weil das eh über die Callbackroutine läuft.

Im Anhang die beiden Bilder von mir.

PS: Jeder Virenscanner hook irgendwelche Sysgtemapis das mach KAV genau so, irgendwie müssen ja die CreateFileNT Operationen abgefangen werden.

Edit: Mein Code oben hat ja kein Fenster. Ich weiß allerdinsg nicht was ShellExecute intern macht. Aber: Es tritt nur auf wenn der aufrufende Prozess geschlossen wird bevor der Aufgerufende beendet ist.

AHT - Fr 07.03.08 17:49

Erst mal besten Dank an dich! Das sieht sehr interessant aus. Die Liste wird auf meinem System leider nicht angezeigt - ist deshalb ganz schwer für mich nachvollziehbar.

Ich habe mal einen Prozess, der beim Beenden mit TerminateProcess keinen Zombie erzeugt, mit TerminazeThread beendet - und wums, ein Zombie war da.

AVIPBB.SYS lädt tatsächlich die Hooks, und zwar laufen die in ein "verstecktes" Stück Code im Kernelspeicher - also an eine Stelle, die sich nicht in einem geladenen Treiber befindet. Das sieht man ja in deinem einen Screenshot recht gut => "not inside kernel module". Avira versucht also das was da beim RootKitscannen abläuft etwas zu verschleiern. Ist auch verständlich (aber wohl nicht effektiv).

Der eigentliche Fehler, der zu dem Problem führt, liegt meiner Meinung nach also nicht im Treiber AVIPBB.SYS selbst, sondern in dem versteckten Stück Code, das da über die Hooks angesprochen wird.

Auf die Hooks bin ich eigentlich nur gestoßen, weil ich auf meinem Testrechner keine Firewall installiert habe; ansonsten hätte ich die auch nicht beachtet und mir wäre es so wie dir gegangen.

AHT - Fr 07.03.08 20:06

Habe gerade noch mal ein Update des Testprogrammes Zombie.exe hochgeladen (Downloadadresse hat sich nicht geändert).

Adressen im Kernel und Modulgrößen werden nun auch hexadezimal angezeigt, außerdem habe ich einen Bug beim Beenden von Prozessen gefixt, der mir bislang nicht aufgefallen war und beim kompilieren entstanden ist.

AHT - Sa 08.03.08 13:01

Erfolg auf ganzer Linie! Im März / April bringt AntiVir ein Update heraus, das scheinbar keine Zombies mehr erzeugt.

AHT - Mo 10.03.08 11:12

Noch ein eventuell wichtiger Hinweis:

Alle die Leute, die AntiVir benutzen und trotzdem keine oder nur einen Zombie gesehen haben, sollten einmal überprüfen, ob der Treiber avipbb.sys von Zombie.exe als geladener Treiber aufgelistet wird.

Fehlt dieser Treiber (wie das zum Beispiel bei FiceGoesDelphi der Fall ist), hat es unter Umständen einen Fehler beim Update von Version 6 auf Version 7 gegeben, was zu einem Sicherheitsloch innerhalb von AntiVir führt. Der Scanner kann dann unter Umständen sehr einfach durch Malware angehalten werden, ohne das der Anwender davon Wind bekommt (NtOpenProcess/NtOpenThread Hook wird nicht installiert).

Wer feststellt, dass avipbb.sys auf seinem System nicht geladen wird, sollte versuchen seine Version von AntiVir komplett zu deinstallieren und nach einem Reboot die Version 7 von der Avira Homepage wieder neu zu installieren.

Calculon - Di 15.04.08 18:13

AHT hat folgendes geschrieben:

Erfolg auf ganzer Linie! Im März / April bringt AntiVir ein Update heraus, das scheinbar keine Zombies mehr erzeugt.

Hallo

AHT,
ich hatte diesen Thread und auch deine Threads bei Avira aufmerksam gelesen, war ich doch auch betroffen von diesen komischen blauen Zombieprozessen. Seit dem gestrigen AntiVir-Update bemerkte ich, dass das Update ewig lang dauerte und der heutige neue Splash-Screen beim Programmstart hat angedeutet, dass eine neue Version draußen ist. Jetzt hab' ich dein Tool mal laufen lassen und folgendes Erfreuliches zu vermelden:

Zitat:

[*** Gefundene PID's ohne sichtbaren Prozess ***]

________________________________________________

:zustimm: Ich bedank' mich mal für deine Aktivität, die dazu geführt hat!

Gruß

Calculon
--

AHT - Mi 16.04.08 09:00

Calculon hat folgendes geschrieben:

AHT hat folgendes geschrieben:

Erfolg auf ganzer Linie! Im März / April bringt AntiVir ein Update heraus, das scheinbar keine Zombies mehr erzeugt.

Hallo

Zitat:

[*** Gefundene PID's ohne sichtbaren Prozess ***]

________________________________________________

:zustimm: Ich bedank' mich mal für deine Aktivität, die dazu geführt hat!

Gruß

Calculon
--

Habe mir ebenfalls die neue Version 8 heruntergeladen. Kann bestätigen, dass der Fehler dort nicht mehr enthalten ist.
Ich habe keine Ahnung, ob das Update immer automatisch funktioniert - nehme eher an, dass das nicht der Fall ist. Ich möchte jedem raten, der noch Version 7 nutzt (egal, ob nun Zombieprozesse entstehen oder nicht), sich die neue Version 8 zur Not direkt von der Avira Homepage herunterzuladen.
Bei den Leuten, die mit Version 7 gearbeitet haben und bei denen keine Zombies zu sehen waren, entstehen unter XP einige Sicherheitslücken, die den PC für Viren angreifbarer machen. Also: Auf jedern Fall Update durchführen!

Da ich speziell von jemandem auf mein Testprogramm hin angesprochen wurde, der das insgesammt für nützlich hielt, habe ich vor einiger Zeit nochmals eine neue Version meines Testprogroggies Zombie.exe hochgeladen. Bei den Treibern werden nun auch die hexadezimalen Adressen angezeigt.
Nochmals zur Bedienung:
Ist bei einem Zombie die Anzahl geöffneter Handles auf den Prozess kleiner als 2, ist der Zombie in der Regel von einem Treiber erzeugt worden. Ist dieser "Handlecount" größer als zwei, ist der Zombie durch ein nicht geschlossenes Prozesshandle (in der Regel im Usermode) entstanden und die PID des "fehlerhaften Programmes" lässt sich durch das Drücken des Buttons Nach Handleeigentümer suchen ermitteln.
Da es sich bei dem Test, den Zombie.exe durchführt, um eine Art von "Kreuzverhörtest" handelt, dürfen, wärend dieser Test läuft, keine Programme gestartet oder beendet werden (gibt sonst falsche Ergebnisse).
Desweiteren überprüft Zombie.exe nicht, ob der gefundene "Zombie" ein RootKit ist oder nicht. Zeigt Zombie.exe im Listview den Pfad des Zombies an oder ist der Exitcode des Prozesses 259 (auch einige unsauber programmierte Programme hinterlassen nach dem Beenden einen solchen Exitcode), sollte man sein System sicherheitshalber mal auf RootKits hin testen.

Ich möchte mich auch noch einmal für das rege Interesse an dem Fall bedanken. Was mich besonders freut, ist der Erfolg, den die Sache gehabt hat. Besser kanns nicht laufen! :zustimm:

Delete - Mi 16.04.08 09:24

Hallo erst mal an alle

Ich nutze Windows XP Pro und SP3 bei mir sind alle grün nix mit blau und hatte etwa drei min gedauert bis es fertig war mit einlesen.

PID: 260
Prozessname: Zombie.exe
Prozesspfad: c:\Downloads\PH\Zombie.exe
Beschreibung des Programmes: Nach Zombieprozessen scannen
Dateiversion: 2,1,0,9
Firma: _
Produktname: Zombie
Produktversion: 2,1,0
Entwickelt für Betriebssystem: 32-Bit Windows
Startzeit des Prozesses: 16.4.2008 um 9:17Uhr, 3sec 323millisec
Zeit des Prozesses im Kernelmode: 40sec 948ms
Zeit des Prozesses im Usermode: 13sec 469ms
PID des Elternprozesses: 2988
Adresse des PEB's: 2147344384
Geöffnet mit Zugriffsrechten: $1F0FFF
Anzahl geöffneter Handles auf den Prozess: 4
Pointer Count: 26
Exitcode: 259
Anzahl geöffneter Handles auf Hooks: 2

________________________________________________
[*** Gefundene PID's ohne sichtbaren Prozess ***]

________________________________________________

mfg Amsel0_0

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!