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.

Jau, da ist er wieder - AntivVir .
Habe meine Ergebnisse erst einmal ins AntiVir Supportforum 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.

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

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.

Sinspin hat folgendes geschrieben:

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

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.

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

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.

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

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.

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

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 ^^

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!

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 ^^ 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!

Und jetzt bitte nochmal auf Deutsch :>

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?

Ok, so weit verstanden.
Vielen Dank!

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

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.

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.

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

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.

Sinspin hat folgendes geschrieben:

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.

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.