Windows braucht sehr lange zum hochfahren (und runterfahren).

[MechUnit]

Mein PC braucht seit ein paar Tagen sehr lange zum Hochfahren. Alleine nach dem Einschalten dauert es lange, bis ich ins UEFI komme.

Aber auch der Startvorgang von Windows danach dauert sehr lange. POST zeigt keine Fehler, Win 10 läuft im EFI-Modus. Fast Boot ist aktiviert, RAM-XMP läuft auch einwandfrei.

Mainboard ist das ASUS Prime X 470-Pro.

Unter Windows sagen Samsung Magician, Crucial Tool und Crystal Disk Info, dass alle Laufwerke ok sind. Das sind 2 NVME M.2 (Samsung 970 Evo Plus 250 GB als System, Crucial P3 2 TB für Games ) und 1 HDD (Seagate 4 TB als Datengrab, Mods und weitere Games). Die Seagate 2 TB habe ich zwar noch eingebaut, aber deaktiviert und ge-lowlevelt. Diese wird auch unter Windows richtigerweise nicht angezeigt.

Um die externe USB 1 TB HD auszuschließen, habe ich diese mal abgesteckt.

Unter o.g. Voraussetzungen lief das System jetzt schon seit ein paar Monaten einwandfrei, auch das Hoch- und Runterfahren ging blitzschnell. Aber seit ca. 1 Woche benötigen der POST und Windows ewig lange zum Starten.

Hatte den PC auch zwischendurch offen und mit dem Kompressor mal wieder gereinigt. Mein Verdacht sind entweder ein SATA-Kabel an den HDD's, ein Win 10 Update oder ein Problem unter Windows selbst bzw. mit der EFI-Bootpartition.

Wenn ich einmal im OS bin, stimmt die Performance allerdings und auch die Stabilität ist wie üblich. Keine Abstürze, nichts.

Das Herunterfahren dauert auch etwas länger als üblich, aber gefühlt geht es noch relativ flott im Vergleich zum langen Bootvorgang.

Irgend etwas hängt da auf jeden Fall - nur was?

 

[cordonbleu]

Wenn auf den HDDs keine systemrelevanten Dateien liegen, kannst du die zum Test einfach mal abklemmen und schauen, ob sich was ändert/bessert.
Aktuellstes Bios ist installiert?

Kannst auch mal testen, ob das Deaktivieren von XMP etwas bringt. Wenn es lange dauert bis du einen Post bekommst, deutet das ja auf längeres Training hin.

Und noch als Tipp: Es wäre nett, die gesamte Hardware im Startpost aufzulisten

 

[MechUnit]

Und noch als Tipp: Es wäre nett, die gesamte Hardware im Startpost aufzulisten

Sorry, schon klar. War nur beim Erstellen des Posts in Gedanken vertieft, welche Maßnahmen ich schon ergriffen habe.

CPU, Board, GPU (Signatur), SSD's und HDD's haben wir ja schon.

Ansonsten ist der RAM genauer 2x 16 GB G.Skill Ripjaws V DDR4 3.200 16-18-18-38 (built in XMP-timings) auf den Slots A2 und B2 im Dual Channel, ein SATA DVD-Brenner und eine Creative X-Fi Xtreme Gamer über PCI-zu-PCI-Express Brücke verbunden. Onboard Sound wird nur für Aufnahmen/Soundeingaben genutzt.

Das Netzteil ist ein be quiet! Straight Power E9 CM 680W. Zwar etwas betagter, aber immer noch einwandfrei.

Edit: Deaktivierung von XMP bringt keinen Unterschied.

Edit 2: ja, aktuelles BIOS (Version 6210) ist zur Unterstützung des Ryzen 5800 X3D installiert.

In der Ereignisanzeige von Windows steht folgendes:

Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.

XML-Screenshot:

Dieser Fehler steht mehrmals in der Ereignisanzeige.

 

[TanteCharlie]

Schau mal bei Crystaldiskinfo auf den Eintrag bei C7 bei der HDD. Wenn da was stehen sollte könnte ein defektes Datenkabel schuld sein. Auch mal testen die Auslagerungsdatei "pagefile.sys" auf Laufwerk C fest einstellen und Windows festlegen lassen.

 

[MechUnit]

Schau mal bei Crystaldiskinfo auf den Eintrag bei C7 bei der HDD. Wenn da was stehen sollte könnte ein defektes Datenkabel schuld sein. Auch mal testen die Auslagerungsdatei "pagefile.sys" auf Laufwerk C fest einstellen und Windows festlegen lassen.

Also aufgrund der Ereignis ID 129 habe ich zunächst mal die HDD's abgeklemmt und werde gleich die 2 TB HDD komplett ausbauen.

Das System ist nach Entfernen der HDD's wieder schneller hochgefahren und Ereignis ID 129 findet im Ereignisprotokoll nicht mehr statt.

Die Auslagerung soll ja auf HDD stattfinden, um die Schreibzugriffe auf SSD zu minimieren.

CrystalDiskInfo kann ich gerne posten, wenn ich gleich die 4 TB HDD wieder eingebaut habe.

 

[Incredible Alk]

Die Auslagerung soll ja auf HDD stattfinden, um die Schreibzugriffe auf SSD zu minimieren.

Bitte vergiss diese urbane Legende.
Du kannst deine SSD nicht "totschreiben" es sei denn du nimmst dir ein paar Monate Zeit um es mit Gewalt absichtlich zu machen.

Hier, meine System-SSD die alles an Schreibarbeit leistet was Windows, Auslagerung usw. hergibt:

Die Platte ist über 5 Jahre alt, geht an die 15000 Betriebsstunden und hat 25 TB geschrieben in der Zeit. Das hat gerade mal zu 42 ersetzten Zellen geführt (von mehreren Tausend vorhandenen) bzw. zu 3% Verschleiß. Rein rechnerisch hält die Platte also noch weitere 150 Jahre bevor sie totgeschrieben wäre...

Lange Rede kurzer Sinn: SSDs sterben an defekten Controllern oder werden über die Jahr(zehnt)e ersetzt weil sie zu klein, zu langsam oder sonstwas geworden sind - aber im privaten Bereich nicht weil zu viel geschrieben wurde.


Selbst mein "Arbeitstier" das arbeitstäglich 20, 30, 40 GB schreiben muss ist dach 57TB/4100h noch bei über 90%:

 

[MechUnit]

Also, nach Komplettausbau der Seagate Barracuda 2 TB ist das Problem behoben und das System startet wieder normal. Bin mir zu 99% sicher, dass es am noch angesteckten SATA-Datenkabel lag, als die HDD noch eingebaut war. Stromkabel eher unwahrscheinlich (die 4 TB HDD läuft über das gleiche Stromkabel) und die HDD war ja bis zuletzt in einwandfreiem Zustand.

Schau mal bei Crystaldiskinfo auf den Eintrag bei C7 bei der HDD. Wenn da was stehen sollte könnte ein defektes Datenkabel schuld sein. Auch mal testen die Auslagerungsdatei "pagefile.sys" auf Laufwerk C fest einstellen und Windows festlegen lassen.

Auslagerung habe ich wieder auf Systemstandard eingestellt und wird jetzt wieder von Windows verwaltet.

C7 ist in einwandfreiem Zustand. Siehe hier:

Bitte vergiss diese urbane Legende.
Du kannst deine SSD nicht "totschreiben" es sei denn du nimmst dir ein paar Monate Zeit um es mit Gewalt absichtlich zu machen.

Hier, meine System-SSD die alles an Schreibarbeit leistet was Windows, Auslagerung usw. hergibt:
Anhang anzeigen 1455034
Die Platte ist über 5 Jahre alt, geht an die 15000 Betriebsstunden und hat 25 TB geschrieben in der Zeit. Das hat gerade mal zu 42 ersetzten Zellen geführt (von mehreren Tausend vorhandenen) bzw. zu 3% Verschleiß. Rein rechnerisch hält die Platte also noch weitere 150 Jahre bevor sie totgeschrieben wäre...

Lange Rede kurzer Sinn: SSDs sterben an defekten Controllern oder werden über die Jahr(zehnt)e ersetzt weil sie zu klein, zu langsam oder sonstwas geworden sind - aber im privaten Bereich nicht weil zu viel geschrieben wurde.

Ja, stimmt. Habe das schon öfters gehört, dass das eine Legende ist, daher habe ich das jetzt wieder umgestellt und die Auslagerung läuft wieder standardmäßig auf der Sytem M.2. C:\.

 

[Waylinkin]

Bitte vergiss diese urbane Legende.
Du kannst deine SSD nicht "totschreiben" es sei denn du nimmst dir ein paar Monate Zeit um es mit Gewalt absichtlich zu machen.

Korrekt. In meinem alten Rechner, der jetzt bei meiner Mutter werkelt, ist meine allererste SD verbaut, 250 GB, die ist gut 15 Jahre alt und funktioniert tadellos.
Eine SSD einbauen und dann nicht nutzen, weil sie kaputt gehen könnte? Da kann ich mir auch einen Ferrari kaufen und in der Garage bunkern, er könnte beim Fahren sich ja abnutzen. ^^

 

[MechUnit]

Korrekt. In meinem alten Rechner, der jetzt bei meiner Mutter werkelt, ist meine allererste SD verbaut, 250 GB, die ist gut 15 Jahre alt und funktioniert tadellos.
Eine SSD einbauen und dann nicht nutzen, weil sie kaputt gehen könnte? Da kann ich mir auch einen Ferrari kaufen und in der Garage bunkern, er könnte beim Fahren sich ja abnutzen. ^^

Wer sagt, dass ich die SSD nicht nutzte? Gar nicht nutzen würde ja u.a. bedeuten, dass kein OS drauf wäre. Aber wir gehen hier OT. Leider hat dein Beitrag nichts mit dem Thema zu tun und stellt auch für andere User keine Lösung dar. Dennoch schön, dass die 15 Jahre alte SSD noch werkelt.

Fakt ist (und auch das wichtige zum Topic): das Problem erkannt und behoben.