🚀 go-pugleaf

Crosspost, Followup-To microsoft.public.de.windows.vista.sonstiges

Hin und wieder blockiert SeaMonkey oder Firefox unter Windows 7 (32-Bit) 
nach dem Auslösen eines Befehls. Dann kehrt z.B. die Grafik des Menüs 
nicht in den Neutralzustand zurück oder das Lesezeichen wird lange nicht 
verschoben. Manchmal erscheint im Fenstertitel der Hinweis "Keine 
Rückmeldung". Zusätzlich wird manchmal das Fenster des betroffenen 
Programmes heller, wobei der Inhalt aber bleibt, es wird nicht weiss. 
Dies dauert zwischen 10 und 90 Sekunden oder auch länger.
Manchmal kann auf das Fenster eines anderen Programmes gewechselt 
werden, manchmal geht auch das nicht.
Es kommt /nicht/ zu Datenverlust.

Es sind schon etliche Versuche zur Diagnose und Beseitigung des Problems 
unternommen worden.
Da auch schon andere Programme blockierten, sind SM und FF 
höchstwahrscheinlich bloss Teilursachen, indem sie z.B. durch hohe 
Belastung in einem anderen Bereich des Systems die Blockierung auslösen. 
Deshalb ist Followup-To in eine System-Gruppe gesetzt.

Mit Hilfe des Task-Managers und vor allem des Ressourcenmonitors wurde 
versucht, Programme oder Prozesse mit (zu) hoher Auslastung aufzuspüren. 
Dabei zeigte sich, dass während den Blockierungen in der Übersicht bei 
"Datenträger" die "Zeit mit max. Aktivität" jeweils auf 100% 
hochschnellt. Im Bereich "CPU" werden dann SeaMonkey oder Firefox rot 
angezeigt. Bei "Datenträger" erscheinen zwar SeaMonkey, Firefox oder 
System bei den Abbild, doch die Liste unterscheidet sich nicht klar von 
der Liste, wenn das System im Normalzutand ist.

Zur Eingrenzung wurde ein früherer Systemzustand auf eine Testpartition 
eingespielt. Verdächtige Programme und Treiber wurden schrittweise 
deinstalliert.
Schliesslich brachte die Installation eines speziellen 
Intel-Sata-Treibers anstelle der Verwendung des im System bereits 
vorhandenen eine so starke Verbesserung, dass im ersten Moment die 
Ursache des Problems vermeintlich gefunden und behoben war.
Da nie Datenverlust erfolgte, war es naheliegend, bei den Blockierungen 
nicht von einem "Fehler", sondern von "schlechter Systemleistung" zu 
sprechen, doch nun würde ich es trotzdem wieder als /Fehler/ bewerten.

Leider gibt es, wenn auch seltener, weiterhin Blockierungen. Es könnte 
sein, dass sie nach dem Wecken aus dem Zustand "Energie sparen" häufiger 
auftreten als sonst, das ist jedoch nicht gesichtert.
Ich vermute, dass das Problem von einem Treiber ausgelöst wird, z.B. von 
einem in einem Programm zum Einbinden von ISO-Dateien als virtuelle 
Laufwerke.

Ziel ist, durch schrittweise Deinstallation von "Verdächtigen" in der 
Testinstallation die Ursache zu finden und das Programm oder den Treiber 
schliesslich wegzulassen oder zu ersetzen.
Das Problem dabei ist, dass bis jetzt noch kein Weg gefunden wurde, mit 
einem /systematischen Stresstest/ nach jeder Deinstallation zu prüfen, 
ob das Problem beseitigt wurde oder nicht. Mit normaler Arbeit und 
aktivem "Herumklicken" auf den Programmen geht es jetzt ziemlich lange, 
bis eine Blockierung (vielleicht) ausgelöst wird.

Fragen:
Mit welchen Verfahren kann man die Wahrscheinlichkeit maximieren, dass 
ein nicht ganz gut programmierter Treiber oder ein solches Programm 
durch die Belastung tatsächlich das fehlerhafte Verhalten zeigt?
Mit welchen Diagnoseverfahren kann man zeigen, in welchem Programm, in 
welchem Treiber, in welcher DLL das Problem auftritt?

- Ueli
-- 
NOTIZ: '_STOP_', '_TAFEL_' und '.invalid' beachten und allenfalls 
entfernen...