WinFuture-Forum.de: Windows 7 friert hängt laggt Freeze Nichts geht mehr - WinFuture-Forum.de

Zum Inhalt wechseln

Hinweis

Alle neuen Themen werden vor der Veröffentlichung durch einen Moderator geprüft und sind deshalb nicht sofort sichtbar.
Seite 1 von 1

Windows 7 friert hängt laggt Freeze Nichts geht mehr Lösung / Workaround


#1 Mitglied ist offline   klawitter 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.408
  • Beigetreten: 21. Februar 08
  • Reputation: 67
  • Geschlecht:Männlich

geschrieben 10. November 2010 - 14:58

Betrifft: Win7 64bit, Vista 64bit, Server 2008 64bit und 2008 r2 im SATA / AHCI-Modus
(32bit-Versionen ungeklärt)

Inhalt
Problembeschreibung
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.

Identifizierung

Zur 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:

Angehängtes Bild: h_nger2.PNG

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)

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:

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

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.


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 verschon
t.

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 :blink: . 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

Android ist die Rache der Nerds - weil wir sie nie auf unsere Parties eingeladen haben.
2

Anzeige



#2 Mitglied ist offline   klawitter 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.408
  • Beigetreten: 21. Februar 08
  • Reputation: 67
  • Geschlecht:Männlich

geschrieben 06. Dezember 2010 - 09:49

Update:

Ich konnte die 'Timing-Hypothese' genauer unter die Lupe nehmen. Ein auf einem Raid0 frisch installiertes Win7 zeigte nach allen Updates (Stand 11/2010) Lags. Über jeweiliges Ein-Ausschalten von C1E-Powerstate sowie NCQ liess sich das Ereignis umgehen bzw gezielt reproduzieren.

Mit HDTune liessen sich veritable Unterschiede in den Random-Acces-Werten und der Burstrate nachweisen. Gerade der letzte Wert gibt Aufschluss darüber, wie schnell Bertriebsystemoperationen von der Festplatte erforderliche Daten zur Verfügung gestellt bekommen.

Im konkreten Fall erwies sich die aktivierung von NCQ als das heilsbringende Moment. Aus mir unerfindlichen Gründen ist NCQ in den AMD-Raid-Treibern nicht automatisch aktiviert, sondern muss erst über ein Web-Frontend namens RaidXpert-Utility eingeschaltet werden.

Die bessere 'Sortierung' der HDD-Zugriffe durch NCQ scheint die Kollision also erfolgreich zu verhindern. Nur, nach allen bisherigen Erfahrungen, gilt das sicher mal wieder nur für den individuellen Einzelfall.
Android ist die Rache der Nerds - weil wir sie nie auf unsere Parties eingeladen haben.
0

#3 Mitglied ist offline   Photongraph 

  • Gruppe: Mitglieder
  • Beiträge: 1
  • Beigetreten: 05. Februar 11
  • Reputation: 0

geschrieben 05. Februar 2011 - 11:55

Hallo klawitter,

dass Problem der Race Conditions bzw. Festplatten Hänger/Freezes durch eine überhöhte Antwortzeit durch fehlerhafte Abarbeitung durch den Controller etc., das zu einen gesamten Programm bzw. System Freeze bzw. Hänger von mehreren Sekunden oder Minuten führte, welches auch ich leider bereits seit mehreren Monaten hatte und mehrfachst durch diverse Updates von Windows und Co. versucht hatte zu beheben (was cheiterte), scheint bei mir jetzt durch einen Chipsatz bzw. Raid-Controller Update gelöst worden zu sein. (das kurioserweise bereits Dezember 2010 erschienen war?)

Hier die Windows Festplattenaktivitätsanzeige in einer normalen ruhigen Phase, wo das System nicht sehr oft auf die Festplatte zugreift:

Angehängtes Bild: race_condition_festplatten_hdd_freeze_stop_hang_gel_st_web.jpg

Anmerkung: Nach dem Systemstart seit dem Treiberupdate scheint die Festplattenaktivitätsanzeige nicht mehr die 97 bis 98% Marke zu überschreiten (bei HD Tune Test nur noch bis max. 99% und Null Hänger), wenn höhere Datenzugriffe durch Programmstarts etc. verursacht werden und seit mehreren Minuten läuft mein System ohne Freezes bzw. lagfrei. Hier scheint der Treiberupdate, eine überhöhte Antwortzeit zu verhindern bzw. das Problem scheint gelöst. ;) :)
Jetzt muss ich aber erstmal das System unter Gaming-Bedinungen (bei mir laggten Spiele intern, wo es durchaus schlimme Soundhänger sogar gab, wo Geräusche in einen Echoeffekt bzw. ins stotterten gerieten, dank der Festplatten Freezes bzw. Race Condition) und Grafikbearbeitungsbedinungen (kurze bis länger andauernde Programm Hänger) ausgiebig testen um wirklich zu wissen, dass das Problem mit einen bloßen Update gelöst ist, aber mein System läuft momentan sehr stabil. Ich bin guter Hoffnung. :wink:

Mein Chipsatz ist der Intel X58 Express Chipsatz
Windows: 7 Ultimate 64-Bit,
HDD/Festplatten: 2x WD Velociraptor im Raid 0 Verbund

Allgemeiner Support Link bei Intel:
http://downloadcenter.intel.com/


Ich würde allen auch die Leute, die einen AMD, nVidia-Chipsatz bzw. andere Systeme und Festplatten-Controller verwenden, einfach die Treiber hierfür zu aktualiesieren. Zumindest scheint bei Intel das Problem der Race Conditions bzw. Freezes / Laggs behoben worden zu sein!

Dieser Beitrag wurde von Photongraph bearbeitet: 05. Februar 2011 - 12:12

0

#4 Mitglied ist offline   evil.baschdi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.639
  • Beigetreten: 11. Februar 07
  • Reputation: 56
  • Geschlecht:Männlich
  • Wohnort:127.0.0.1, breites #Neuland
  • Interessen:IT, Musik

geschrieben 22. Februar 2011 - 12:57

Mahzeit. Häng mich mal mit einem ähnlichen Problem hier ran:

Notebook; In den meisten Games (NFS World, BF Play4Free Beta, Fuel Demo...) hab ich immer mal wieder ruckler, wie wenn das Notebook mit Handbremse betrieben würde. Ich kann aber weiterspielen, nach kurzer Zeit ist das Ruckeln dann wieder weg. (C2D T9400 @ 2,53 GHz, GeForce FX 9600M GT mit aktuellstem Treiber, 4GB Ram, 64bit).
Zudem war jetzt schon zwei mal der Fall, dass ich nicht mehr starten konne und dass ich Windows zum "zuletzt bekannten erfolgreichen Start" wiederherstellen musste.
Beide Probleme müssen nicht zwingen vom SP1 kommen, Schadsoftware habe ich auch nicht gefunden.

Hab tatsächlich auch mit dem AHCI Treiber gebastelt. Von Acer bekam ich Version 8 angeboten, bei Intel Version 10. Nachdem ich Version 10 installierte hatte ich mein erstes "Windows konnte nicht gestartet werden" Problem. Hab in diesem zuge den Treiber (hoffentlich) wieder deinstalliert.
Version 8 könnte ich entweder mal wieder drüberschieben oder nochmal Version 10, weiß aber nicht, ob ich der mittlererweile trauen kann und das Problem evtl wo anders lag. Zudem soll ja mit dem SP1 ein neuer AHCI Treiber gekommen sein.

Wie soll ich weiter vorgehen?
Eingefügtes Bild

"
Heute code ich, morgen debug ich und übermorgen caste ich die Königin auf int!"
P.S. Ich leiste keinen Support per PN. Wer ein Problem hat, ab damit ins Forum!
Windows 10 - Windows Anleitungen
0

#5 Mitglied ist offline   evil.baschdi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.639
  • Beigetreten: 11. Februar 07
  • Reputation: 56
  • Geschlecht:Männlich
  • Wohnort:127.0.0.1, breites #Neuland
  • Interessen:IT, Musik

geschrieben 22. Februar 2011 - 21:00

Also Version 10 Verursacht die Fehler. :-/ Hoffe Acer veröffentlicht im Zuge des SP1 eine aktualisierte Version.
Eingefügtes Bild

"
Heute code ich, morgen debug ich und übermorgen caste ich die Königin auf int!"
P.S. Ich leiste keinen Support per PN. Wer ein Problem hat, ab damit ins Forum!
Windows 10 - Windows Anleitungen
0

#6 Mitglied ist offline   herr.noskill 

  • Gruppe: Mitglieder
  • Beiträge: 1
  • Beigetreten: 03. Juli 11
  • Reputation: 0

geschrieben 03. Juli 2011 - 11:57

Hey, erstmal vielen Dank für die ausführliche Hilfestellung.
Bei mir haben die verschieden Treiber Intel, Windows nix gebracht auf dem 2008r2.
Jedoch bin ich guter Dinge das Problem durch einen geringeren Arbeitspeichertakt gelöst zuhaben.
i3 8gb mit 1066

update: es ist besser, aber nicht weg...

Dieser Beitrag wurde von herr.noskill bearbeitet: 03. Juli 2011 - 12:33

0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0