Hilfe
Neues Thema
Antworten
(32bit-Versionen ungeklärt)
Inhalt
Problembeschreibung
Identifizierung des Fehlers
Ursache
6 verschiedene Lösungen
Identifizierung des Fehlers
Ursache
6 verschiedene Lösungen
Problembeschreibung
Während der Installation von Windows 7, direkt danach, nach Updates, nach einem Wechsel von IDE auf AHCI oder nach Deinstallation eines Hersteller-AHCI-Treibers und Neuinstallation des windowseigenen AHCI-Treibers und umgekehrt bleibt Windows 7 mehrfach und mitunter bis zu 30 Minuten am Stück hängen. Die Maus lässt sich weiter bewegen, es erfolgt keine Fehlermeldung und Eingaben finden nur mit extremer Verzögerung statt. Oft wiederholt sich diese Situation so schnell, dass sich nicht einmal ein Mausklick dazwischen absetzen lässt.
IdentifizierungZur Identifikation dieses Problems muss der Ressourcenmonitor geöffnet werden. Entweder über den Button <Ressourcenmonitor> im Taskmanager, Reiter <Leistung>, oder über die Eingabe <resmon> im Suchfeld des Startmenues.
In der grafischen Darstellung der Festplattenaktivität zeigt sich dann ein ähnliches Bild wie dieses:
Der durch den grünen Graphen dargestellte Datendurchsatz ist sehr gering, die Festplattenauslastung, durch die blaue Linie dargestellt, aber über grosse Zeiträume bei 100%.
Die Angabe < x% Zeit mit max. Aktivität > in der Leiste der Datenträgerüberwachung steht ebenso häufig bei 100%.
Die Werte in der Spalte < Antwortzeit(ms) > liegen teils im sechsstelligen Bereich.
CPU- und RAM-Last sind sehr gering.
Ursache (Wenns interessiert, ansonsten: Weiterscrollen zu Lösungen)In der grafischen Darstellung der Festplattenaktivität zeigt sich dann ein ähnliches Bild wie dieses:
Der durch den grünen Graphen dargestellte Datendurchsatz ist sehr gering, die Festplattenauslastung, durch die blaue Linie dargestellt, aber über grosse Zeiträume bei 100%.
Die Angabe < x% Zeit mit max. Aktivität > in der Leiste der Datenträgerüberwachung steht ebenso häufig bei 100%.
Die Werte in der Spalte < Antwortzeit(ms) > liegen teils im sechsstelligen Bereich.
CPU- und RAM-Last sind sehr gering.
Der Grund für das Phänomen liegt in der Erfüllung einer 'Racecondition'. Der daraufhin eintretende Race Hazard blockiert nachfolgende Schreib- und Lesezugriffe auf die Festplatte. Der Datendurchsatz ist nahezu vollständig geblockt und alle Operationen, die auf Festplattenzugriffe angewiesen sind, hängen.
Das Risiko, dass es zum Race Hazard kommt, steigt unter einer vorhandenen Racecondition bei sehr vielen Zugriffen binnen kurzer Zeit. Diese finden typischeweise während oder direkt nach einer Installation von Windows statt. Zwar tritt das Phänomen auch meist in dieser Situation auf, grundsätzlich kann es jedoch jederzeit in den verschiedensten Betriebszuständen passieren.
Microsoft erklärt, die Racecondition werde duch einen Fehler bzw eine Eigenart in der AHCI-Treiberdatei Msahci.sys geschaffen. Während des Race Hazard funktioniert das Zusammenspiel des Interrupthandlers des AHCI-Treibers mit dem Controller nicht mehr. Abgeschlossene Operationen werden nicht als erfolgreich beendet erkannt. Durch die Operation vorgenommene Sperrungen bleiben bestehen, bis das Timeout nach 60 Sekunden erfolgt. Erst der Timeouthandler stellt dann die korrekte Information zu Verfügung. Besteht der Race Hazard weiterhin, folgt die gleiche Situation direkt darauf. Das kann sich auch mal über 30 Min am Stück hinziehen.
Tiefer geht MS nicht darauf ein. Wohl aus gutem Grund, denn auch mit den AHCI-Treibern der unterschiedlichen Chiphersteller besteht offensichtlich diese Racecondition und es kommt auch da zum Race Hazard. Bei unverändertem Setup und unveränderter Software lässt das Ereignis reproduzieren.
Interessant ist ebenfalls, dass sich in manchen Fällen mit Veränderungen in der ACPI das Ereignis quasi an- und abschalten liess.
Eine Racecondition entsteht, wenn Operationen, die sich gegenseitig beeinflussen können oder untereinander absichtliche oder unabsichtliche Abhängigkeiten haben, nicht korrekt getimed, prioisiert oder durch temporäre Umbennenungen von z.B. gemeinsam genutzten Daten entflochten worden sind. Die Abhängigkeit kann dabei auch rein zufälliger Natur sein, wie durch den Zugriff auf identische Daten. Wenn der Zufall es also will, kommt es zu dieser Kollision.
Meine These, dass es nicht (nur) am AHCI-Treiber selbst liegt, sondern (oder und?) evtl. an einem nicht definierten Timing bzw. Prioritäten bestimmter Operationen von Windows, stützt sich auf folgende Tatsachen:
Bei bestimmten 'unglücklichen' zeitlichen Umständen kommt es eben zu dieser Kollision. Kollidieren die verursachenden Operationen zeitlich nicht, bleibt man von diesem Problem verschont.Das Risiko, dass es zum Race Hazard kommt, steigt unter einer vorhandenen Racecondition bei sehr vielen Zugriffen binnen kurzer Zeit. Diese finden typischeweise während oder direkt nach einer Installation von Windows statt. Zwar tritt das Phänomen auch meist in dieser Situation auf, grundsätzlich kann es jedoch jederzeit in den verschiedensten Betriebszuständen passieren.
Microsoft erklärt, die Racecondition werde duch einen Fehler bzw eine Eigenart in der AHCI-Treiberdatei Msahci.sys geschaffen. Während des Race Hazard funktioniert das Zusammenspiel des Interrupthandlers des AHCI-Treibers mit dem Controller nicht mehr. Abgeschlossene Operationen werden nicht als erfolgreich beendet erkannt. Durch die Operation vorgenommene Sperrungen bleiben bestehen, bis das Timeout nach 60 Sekunden erfolgt. Erst der Timeouthandler stellt dann die korrekte Information zu Verfügung. Besteht der Race Hazard weiterhin, folgt die gleiche Situation direkt darauf. Das kann sich auch mal über 30 Min am Stück hinziehen.
Tiefer geht MS nicht darauf ein. Wohl aus gutem Grund, denn auch mit den AHCI-Treibern der unterschiedlichen Chiphersteller besteht offensichtlich diese Racecondition und es kommt auch da zum Race Hazard. Bei unverändertem Setup und unveränderter Software lässt das Ereignis reproduzieren.
Interessant ist ebenfalls, dass sich in manchen Fällen mit Veränderungen in der ACPI das Ereignis quasi an- und abschalten liess.
Eine Racecondition entsteht, wenn Operationen, die sich gegenseitig beeinflussen können oder untereinander absichtliche oder unabsichtliche Abhängigkeiten haben, nicht korrekt getimed, prioisiert oder durch temporäre Umbennenungen von z.B. gemeinsam genutzten Daten entflochten worden sind. Die Abhängigkeit kann dabei auch rein zufälliger Natur sein, wie durch den Zugriff auf identische Daten. Wenn der Zufall es also will, kommt es zu dieser Kollision.
Meine These, dass es nicht (nur) am AHCI-Treiber selbst liegt, sondern (oder und?) evtl. an einem nicht definierten Timing bzw. Prioritäten bestimmter Operationen von Windows, stützt sich auf folgende Tatsachen:
- Der Fehler lässt sich nicht an bestimmter Hardware festmachen.
- Es gibt keine bestimmten Kombinationen aus Chipsatz und Festplatte.
- Identische Paarungen von Betriebssystem, Treiber, Controller und Festplatte auf Boards verschiedener Hersteller verhalten sich bereits unterschiedlich.
- Veränderungen in der Energieverwaltung, die Einfluss auf (manche) Systemtimings nehmen, (siehe ACPI, hier vor allem die ATK0110 Utility von Asus) können den Zustand provozieren oder auflösen.
Lösungen
1.MS Hotfix
MS sieht einen nicht den AHCI-Spezifikationen entsprechenden Zugriff(sweg) der Msahci.sys als Ursache und bietet dafür einen Hotfix an. Wer möchte, kann auf die deutsche Version auf der verlinkten Seite umschalten, allerdings birgt die automatische Übersetzung einige inhaltliche Fehler.
Dass aus dem Hotfix noch kein Update geworden ist, deutet darauf hin, dass man der Sache zwar auf der Spur ist, aber es noch nicht vollständig aufgelöst hat.
Denn: es funktioniert keineswegs in jedem Fall - und natürlich schon gar nicht, wenn man einen anderen AHCI-Treiber nutzt.
2.Treiberwechsel
MS -> Chiphersteller
Ist man mit dem MS-Hotfix erfolglos, kann die Installation des Herstellertreibers des Satacontrollers statt des Windowpendants helfen. Dieser befindet sich in der Southbridge, sofern man keinen Zusatzcontroller verwendet. Die aktuellen AHCI-Treiber werden von der Website von AMD, Intel oder Nvidia heruntergeladen und sollten, sofern man erst mal nur eine *.exe bekommt, mit einem Packprogram wie 7zip entpackt werden. Mit etwas Stöbern in den entpackten Daten findet man die AHCI-Treiberdatein. Durch Ausführung der Setup.exe lässt sich der Treiber mitunter nicht erfolgreich installieren, da der Windowstreiber installiert ist. Deshalb ist der Umweg über den Gerätemanger nötig:
[Windows+Pause], in der linken Spalte den Gerätemanger wählen.
Unter < IDE ATA/ATAPI-Controller> wird jeder (verbleibende) Serial-ATA und AHCI-Eintag per Rechtsklick und folgendem Klick auf < Treiber aktualisieren > mit dem neuen Treiber versehen:
[Klick] < Auf dem Computer nach Treiberspftware suchen >
[Klick] < Durchsuchen>
und im erscheinenden Fenster bis zu den Treiberdaten navigieren.
[Klick] OK, und der Treiber sollte installiert werden.
!! - Viele Chipsätze können ausgewählte Ports (oft Port 5 +6) gesondert im IDE /Native-Mode betreiben, im SATA /AHCI-Modus werden sie nur unter dem Herstellertreiber erkannt. Also, bei Unklarheit vorher im Bios nachschauen, was wie konfiguriert ist. In erster Linie geht es nur um die Gruppe an Ports, an denen die Systemplatte angebunden ist.
Die ebenfalls in vielen Chips noch verbauten und unter < IDE ATA/ATAPI-Controller> aufgeführten PCI-IDE-Controller bleiben von dem Eingriff ebenso verschont.
Nach einem Neustart ist der Windowstreiber dann durch den Herstellertreiber ersetzt.
Alternativ kann man den Treiber bereits mit der Installation von Windows während des Setupprozesses laden.
Chiphersteller -> MS
Im ungekehrten Fall, also wenn der Fehler unter dem Treiber des Chipherstellers auftaucht, sollte man zuerst alle Daten zur Treiberinstallation (Repository) löschen. Diese befinden sich meist im Verzeichnis C: in einem direkten Ordner namens ATI /AMD, Nvidia oder Intel. Das soll verhindern, dass Windows nach dem Neustart darauf zugreift.
Anschliessensd öffenet man den Gerätemanager
[Windowstaste+Pause], in der linken Spalte den Gerätemanger wählen.
Unter < IDE ATA/ATAPI-Controller> mit Rechtsklick auf die Einträge gehen und <Deinstallieren> wählen. Auf Nachfrage die vollständige Deinstallation inkl. Treiber bestätigen. Keine Sorge, auch der Anschluss der Systemfestplatte wird so entfernt.
Nach dem anschliessenden Neustart installiert Windows automatisch den eigenen Treiber.
Zur Info: Mit installiertem Herstellertreiber wird der Controller ggf nur mit einem Eintrag, unabhängig von der Anzahl der Kanäle, angezeigt. Mit dem Windowstreiber bekommt jeder Kanal einen eigenen Eintrag.
Um allem Ungemach vorzubeugen: Eine Datensicherung vor solchen Aktionen schadet nie und sei wärmstens empfohlen. Bei einem frisch installierten System kann man aber durchaus darauf verzichten, schlimmstenfalls muss man halt neu installieren.
3.Hardwaretausch
Wenn sich die Gelegenheit bietet, z.b.eine alternative Festplatte zur Hand ist oder sich das frisch erstandene Exemplar noch umtauschen lässt, ist der Austausch der Festplatte durch ein alternatives Modell ein absolut gangbarer und ziemlich erfolgssicherer Weg. Andere beteiligte Hardwarekomponenten gibt es ausser dem Mainboard nicht - das wäre aber zu viel an Aufwand, wenngleich auch möglich und zielführend.
4.IDE / Native-Modus
Wirksam, aber wegen der technisch wesentlich bescheideneren Funktion des 'Native-Modus' nicht zu empfehlen. Falls es doch, als letzter Anker, sein soll: Der Modus wird im Bios eingestellt. -> Handbuch.
5.Timing-Hypothese
Ich habe derzeit keine Systemkombination, bei der dieses Problem auftaucht - ich hatte aber auch schon beileibe genug
. Daher kann ich diese Hypothese derzeit nicht überprüfen. Der Gedanke ist, dass sich aus dem Konglomerat von Bios-> Systemtimings-> Windows-> Timetables-> Controller /Treiber /Festplatte genau die zeitliche Konstellation ergibt, die die kollidierenden Operationen / Aufrufe zustande kommen lässt. Wie oben schon versucht zu erklären, leite ich das aus der Tatsche ab, dass einer Racecondition immer ein Timing/Prioritätenproblem zugrunde liegt und veränderte SB-Energieverwaltungseinstellungen, die auch die Timings der SB beeinflussen (man kann das an veränderten Datenraten erkennen), offensichtlich Abhilfe schaffen.
Ausserdem: Auf der überwiegenden Mehrzahl der Systeme taucht dieses Problem nie auf und betroffene Komponenten arbeiten in anderen Konstellationen völlig fehlerfrei.
Also, einen Versuch ist es allemal wert, wenn bislang nichts geholfen hat.
Sonderfall Asus:
Bei Asus-Boards sollte man im Problemfall die automatischen Windows-Updates während der Installation auf manuell stellen. Nach dem ersten Systemstart nach der Installation durchsucht man die Updateliste nach dem Eintrag <ATK0110 Utility>. Dieses, Asus-Boards eigene Update deaktiviert man und blendet es aus (Häckchen entfernen und per Rechtsklick etc.) Anschliessend kann man das automatische Update (empfohlen!) wieder aktivieren. Ist Windows nach ein paar Stunden oder Tagen mit allen Updates und Indexierungen durch (-> die Random Acces-Zugriffe werden weniger heftig), kann man das ATK-Update wieder rauskramen und auch installieren. Lebensnotwendig ist es nicht, aber es hilft Energie zu sparen.
Gute Chancen damit hat, wer natürlich ein Asus-Board besitzt und des weiteren feststellt, das der RaceHazard erst nach dem ersten Neustart des fertig installierten Systems eintritt. Denn da werden die Einstellungen des ATK-Updates übernommen.
Ansonsten:
Wer kein Asus-Board und oder kein Problem mit dem ATK-Update hat, kann sich auf anderem Wege an die Timings des Systems heran machen. Zwei einfache Wege sind die Energieeinstellungen und die Speicher-Geschwindigkeit. Die vom Bios mitkontrollierten Energiespareinstellungen beeinflussen die Bildung der Timetables, also der Taktzyklenvorgaben, die Windows beim Booten für das ganze System mit der Hardware 'aushandelt'. Bekannt sind Timings beim Ram, aber das ganze System unterliegt sochen Einstellungen. Verschiedene Energiesparmodi beeinflussen diese Timetables - weniger Spannung bei entspannteren Latenzen. Bietet das Bios die Wahlmöglichkeit zwischen verschiedenen ACPI-Modi (1 bis 3), kann man da eine alternative Einstellung testen. Die vorübergehende Deaktivierung (im BIOS) von Prozessorsparmodi (Cool&Quiet, EIST) bis einige Zeit nach der Installation ist ebenso eine Option. Die C-States der CPU kann man aktivieren/deaktivieren (ebenfalls BIOS). Da sich all diese Einstellungen auf die Übertragungsraten der SB-Controller auswirken (mal stärker, mal weniger), lässt sich auf veränderte Latenzen schliessen. Genau das ist der Punkt, mit dem wir versuchen, die Kollision konkurrierender I/O Operationen zu umgehen.
Der andere Ansatz ist, den Ram so zu takten, dass das System andere Hauptlatenzen anlegt. Bei aktuellen AMD-Prozessoren findet dieser 'Switch' bei der Umstellung zwischen 800 Mhz und 1066 Mhz oder mehr statt.
Auch eine Rücknahme der Anbindungsgeschwindigkeit von CPU / Northbridge zu Southbridge /Sata-Controller (QPI, HT-Link etc) kann diese Timings ggf. beeinflussen.
6.Zeit
Ganz getreu dem homöopathischen Grundsatz, Gleichem mit Gleichem zu begegnen, gibt es auch eine höchst homöopathische Lösung: Den Rechner einfach machen lassen. Nach einigen Stunden bis 3 Tagen ist der ganze Spuk von selbst vorbei.
Lösungen im Sinne von 'Problem beseitigt' sind das nicht, denn die Racecondition bleibt in allen Fällen weiterhin latent vorhanden. Sie tritt aber nur bei extrem hohen I/O-Werten auf, und der Randomacces ist nunmal im Umfeld der Installation und der ganzen Updaterei sowie Indexierung besonders hoch, wenn nicht gar am höchsten. Ausserdem sind es ja nicht alle, sondern nur eine oder wenige bestimmte Operationen, die die Racecondition bilden und den Race Hazard verursachen können. Letzlich geht es nur darum, diese Klippe zu umschiffen. Diesen Bug - denn imho ist es einer - kann nur MS beseitigen.
Dieser Beitrag wurde von klawitter bearbeitet: 06. Dezember 2010 - 09:29
Nach oben
