LÖSUNG: Es lag die ganze Zeit an den RAM-Einstellungen :-| Mir ist nie in den Sinn gekommen, dass die Standardeinstellungen auf einer Standardplatine mit Standard-RAM so weit davon abweichen könnten, dass das System instabil wird. Ich habe noch nie übertaktet und mir diese Einstellungen daher nie genau angesehen. Nachdem ich das DOCP-Profil ausgewählt hatte, das zu meinem RAM passte, klärte sich alles auf und es ist sogar ein bisschen schneller. Danke an Twisty Impersonator für die Anleitung und an magicandre1981 für den Vorschlag, der mich dazu veranlasst hat, die Einstellungen zu überprüfen. Hoffentlich erspart das jemand anderem zwei Jahre Frustration.
EDIT: Nun, ich denke, die Ursache ist klar geworden. Nachdem ich die GESAMTE Hardware ausgetauscht hatte und IMMER NOCH ein Problem sah, beschloss ich, zur Hardware-Idee zurückzukehren. Kurz gesagt: Wenn ich mit zwei RAM-Riegeln arbeite, ist alles in Ordnung. Es ist egal, welche zwei Riegel es sind. Wenn ich alle vier einsetze, bekomme ich Probleme. Dies scheint ein ziemlich eindeutiger Hinweis auf ein defektes Motherboard zu sein.
Die Symptome:
In den letzten Jahren war mein Rechner generell instabil, mit Unterbrechungen. Normalerweise äußert sich dies in Form von BSODs mit unterschiedlichen Stoppcodes.
- Durch ein Upgrade des RAM wurde die Stabilität vorübergehend verbessert.
- Durch ein Upgrade des Motherboards wurde die Stabilität vorübergehend verbessert.
- Durch den Austausch des
C:Laufwerks wurde die Stabilität vorübergehend verbessert. - Eine Aktualisierung oder Neuinstallation des Betriebssystems kann gelegentlich erforderlich sein und verbessert normalerweise für eine gewisse Zeit die Stabilität.
Ich habe praktisch jede funktionale Komponente im System ersetzt, außer der CPU und dem Blu-ray-Laufwerk. Ich habe die CPU nicht ausgeschlossen, aber es gibt noch jede Menge Software-„Dinge“, die ebenfalls schuld sein könnten.
Jedes Mal trat das Problem nach einigen Monaten wieder auf.
In letzter Zeit haben sich die Symptome leicht verändert. Ich bin offen für die Möglichkeit, dass dies ein völlig anderes Problem ist, aber es scheint den Problemen, mit denen ich die ganze Zeit zu kämpfen hatte, zu ähnlich zu sein, als dass es bloßer Zufall sein könnte.
Vor ein paar Wochen habe ich meinen Computer neugestartet, um ihn zu aktualisieren, aber er ließ sich nicht laden POST. Ich habe eine Weile damit herumgespielt (Verbindungen, MemOK!Tasten, Strom trennen, TPUEin/Aus, EPUEin/Aus usw.) und habe ihn zum Laden gebracht POST, aber das Betriebssystem ließ sich nicht laden. Ich habe die genaue Symptomatik vergessen, aber wenn ich mich recht entsinne, lief er einfach nur und drehte sich.
Ich habe das Betriebssystem neu installiert und ungefähr eine Woche lang war alles ruhig, bis Apps abzustürzen begannen. Zunächst schien es, als wären alle Apps, die abstürzten, auf derselben SSD installiert. Da ich keinen Platz hatte, um Dinge zu verschieben und zu testen, habe ich auf die neuen Samsung-Laufwerke aufgerüstet. Aber Apps stürzen immer noch ab.
- Letztes BIOS-Update geflasht. Keine Änderung.
- Es stellte sich heraus, dass Sie das CMOS zurücksetzen müssen, wenn Sie das BIOS flashen. Mögliche Symptome ähneln meinen. Ich habe das CMOS zurückgesetzt. Keine Änderung.
- Normalerweise stürzten Anwendungen mit hohen Anforderungen ab (Dishonored 2, Diablo III, ESO usw.). Aber Abstürze treten bei Temperaturen zwischen 35 °C und 45 °C für CPU und GPU auf – also wahrscheinlich nicht aufgrund der Temperatur.
- Der Arbeitsspeicher geht nicht aus.
MemTesthat nie Probleme gezeigt. Ich habe es Dutzende Male ausgeführt.- Kein CPU-Test hat jemals Probleme gezeigt, außer bei hohen Temperaturen.
- Kein GPU-Test hat jemals Probleme gezeigt, außer bei hohen Temperaturen.
- Ich habe meine Grafiktreiber einige Dutzend Mal neu installiert.
- Beim Zuschauen gestern ist der Task-Manager abgestürzt.
- Habe versucht, eine Windows Store-App zu installieren. Ein Hintergrundprozess stürzte ab. Musste es erneut versuchen. Funktionierte einwandfrei.
- Die Ereignisanzeige enthält nur
AppCrashEreignisse
AppCrashEreignisse werden von einer Vielzahl von Anwendungen erzeugt. Unterschiedliche Größen, Standorte, Anforderungen usw. Normalerweise passiert das einmal am Tag, vielleicht auch weniger. Aber Anwendungen mit hohen Ressourcenanforderungen stürzen ziemlich zuverlässig innerhalb von etwa 30 Minuten ab.
Ich sollte klarstellen, dass dies keine Windows is looking for a solutionAppHang-Ereignisse sind. Die Anwendung verschwindet einfach, als hätte ich sie geschlossen, und Windows hat nichts dazu zu sagen, außer dem AppCrash-Ereignis in der Ereignisanzeige. Seltener kommt es zu einem BSOD. In letzter Zeit habe ich gesehen IRQ not less than or equalund andere, an die ich mich nicht erinnern kann ... (Ich habe keine Speicherauszüge mehr? Das ist komisch ...).
Systemspezifikationen:
- Betriebssystem:Windows 10 Pro (Upgrade von Win7 während des kostenlosen Upgrade-Zeitraums)
- CPU:AMD Phenom II 1090 (kein Übertakten)
- Kühlung:CoolerMaster 150mm CPU-Lüfter, mehrere Gehäuselüfter
- Mainboard:ASUS M4A99X EVO R2.0
- RAM:G.Skill 16 GB (4 x 4) DDR3-1333
- Grafikkarte:MSI GTX 970 (kein Übertakten)
- Netzteil:Corsair CX750M
- Systemlaufwerk:Samsung 850 EVO 500 GB
- Andere Laufwerke:Samsung 850 EVO 500GB, andere konventionelle Laufwerke, optisches Laufwerk
- EIN V:Windows Defender, kein anderer Antivirus
Absturzspeicherauszug:
Angeregt durch diesen Beitrag:https://superuser.com/questions/1281659/möglich, festzustellen, auf welchem Kern sich eine fehlerhafte Anwendung befand, als sie abstürzte
Gestern Abend ist im Leerlauf ein neuer BSOD aufgetreten. Einzelheiten siehe WhoCrashedunten:
Crash dump directory: C:\WINDOWS\Minidump
Crash dumps are enabled on your computer.
On Wed 1/3/2018 9:00:13 AM GMT your computer crashed
crash dump file: C:\WINDOWS\Minidump\010318-12546-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x1640E0)
Bugcheck code: 0x1E (0xFFFFFFFFC0000005, 0xFFFFF8019CED183E, 0xFFFF968442FBEB68, 0xFFFF968442FBE3B0)
Error: KMODE_EXCEPTION_NOT_HANDLED
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows®
Operating System company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a kernel-mode program generated an exception
which the error handler did not catch. This appears to be a typical software driver bug
and is not likely to be caused by a hardware problem. The crash took place in the Windows
kernel. Possibly this problem is caused by another driver that cannot be identified at this time.
On Wed 1/3/2018 9:00:13 AM GMT your computer crashed
crash dump file: C:\WINDOWS\memory.dmp
This was probably caused by the following module: ntdll.sys (ntdll!ZwFlushBuffersFile+0x14)
Bugcheck code: 0x1E (0xFFFFFFFFC0000005, 0xFFFFF8019CED183E, 0xFFFF968442FBEB68, 0xFFFF968442FBE3B0)
Error: KMODE_EXCEPTION_NOT_HANDLED
Bug check description: This indicates that a kernel-mode program generated an exception
which the error handler did not catch. This appears to be a typical software driver bug
and is not likely to be caused by a hardware problem. A third party driver was identified
as the probable root cause of this system error. It is suggested you look for an update for
the following driver: ntdll.sys.G
Google query: ntdll.sys KMODE_EXCEPTION_NOT_HANDLED
Speicherauszüge (vollständig und Mini) werden hier angezeigt, sobald sie verfügbar sind:https://1drv.ms/f/s!AhSzRvnavkrXhPpNy8Qjhaj6LbbTwQ
@magicandre1981 empfohlen chkdsk /fbasierend auf den Ergebnissen meines Speicherauszugs. C:ist das einzige Laufwerk, für das eine Auslagerungsdatei aktiviert ist (es wird vom System verwaltet), also habe ich es auf diesem ausgeführt. Hier sind die Ergebnisse:
Dateisystem auf C: wird geprüft: Der Typ des Dateisystems ist NTFS.
A disk check has been scheduled.
Windows will now check the disk.
Stage 1: Examining basic file system structure ...
605184 file records processed. File verification completed.
Deleting orphan file record segment 699DD.
10717 large file records processed. 0 bad file records processed.
Stage 2: Examining file name linkage ...
14846 reparse records processed. 704776 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered to lost and found. 14846 reparse records processed.
Stage 3: Examining security descriptors ...
Cleaning up 1426 unused index entries from index $SII of file 0x9.
Cleaning up 1426 unused index entries from index $SDH of file 0x9.
Cleaning up 1426 unused security descriptors.
Security descriptor verification completed.
49797 data files processed. CHKDSK is verifying Usn Journal...
37651904 USN bytes processed. Usn Journal verification completed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.
No further action is required.
487284001 KB total disk space.
209659436 KB in 259738 files.
162276 KB in 49798 indexes.
0 KB in bad sectors.
729085 KB in use by the system.
65536 KB occupied by the log file.
276733204 KB available on disk.
4096 bytes in each allocation unit.
121821000 total allocation units on disk.
69183301 allocation units available on disk.
Internal Info:
00 3c 09 00 f0 b8 04 00 7e 93 08 00 00 00 00 00 .<......~.......
98 05 00 00 66 34 00 00 00 00 00 00 00 00 00 00 ....f4..........
Windows has finished checking your disk.
Please wait while your computer restarts.
Kein Glück. Auch nachdem chkdsk diese Probleme behoben hat, habe ich immer noch die gleichen Abstürze, allerdings noch keine neuen BSODs.
Ein weiterer BSOD, als ich den Browser öffnete, um diese Frage zu aktualisieren. Memdumps verfügbar, sobald der Upload abgeschlossen ist.
Aber der ursprüngliche Grund, warum ich das Update gemacht habe, ist, dass ich eine ganze Menge (51, um genau zu sein) von Ereignissen gefunden habe, die genau gleich aussehen. Es sieht so aus, als ob sie etwa jede halbe Stunde passiert sind, angefangen gleich nachdem ich zur Arbeit gegangen bin (7:30 Uhr) bis etwa 20:30 Uhr. Sie könnten immer noch passieren. Sie sehen alle so ausgenauDas:
Fault bucket 0x1E_c0000005_fltmgr!FltpPreFsFilterOperation, type 0
Event Name: BlueScreen
Response: Not available
Cab Id: 0
Problem signature:
P1: 1e
P2: ffffffffc0000005
P3: fffff8019ced183e
P4: ffff968442fbeb68
P5: ffff968442fbe3b0
P6: 10_0_16299
P7: 0_0
P8: 256_1
P9:
P10:
Attached files:
\\?\C:\WINDOWS\Minidump\010318-12546-01.dmp
\\?\C:\WINDOWS\TEMP\WER-18531-0.sysdata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER5795.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER57A5.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER57B6.tmp.txt
\\?\C:\Windows\Temp\WER8F12.tmp.WERDataCollectionStatus.txt
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_1e_b49232881f44bde28acca17f0ad8bac3b4fbb67_00000000_cab_031c57c4
Analysis symbol:
Rechecking for solution: 0
Report Id: 3c2abe43-d7d6-4561-9b0d-2adf1f40c745
Report Status: 388
Hashed bucket:
Ich kann kaum glauben, dass die CPU dieses Problem so lange hat und der Computer trotzdem noch funktioniert. Ich hatte bei der Untersuchung von Software-/Konfigurationsproblemen nicht viel Erfolg.
Irgendwelche Ideen?
Fast 3 Wochen später... Nach VIEL Schabernack habe ich mir endlich eine neue CPU zugelegt (Upgrade von Phenom II auf FX-8350). Der Austausch war recht einfach. Dann habe ich die üblichen Problembereiche untersucht und die Apps stürzen immer noch ab.
Sobald ich „trauriges Gesicht“ gepostet hatte, teilte mir Windows etwas über einen „Gerätezustandsbericht“ mit. Darin wird ein Problem mit einem Treiber gemeldet. Leider, aber wenig überraschend, konnte die Problembehandlung keinerlei Probleme erkennen. Ich habe die beiden „USB Root Hub“-Geräte im Fehlerzustand aus dem Geräte-Manager deinstalliert.
Gibt das weitere Hinweise? Ich bin jetzt wirklich ratlos ...
Hier ist eine Liste mit Treiberinformationen …? https://docs.google.com/spreadsheets/d/1xAliAOt1s8rQ_ePX5OwTRVFPB3kFYgc3-1HRUznMpR0/edit?usp=sharing
Antwort1
Teile und herrsche
Versuchen Sie zunächst herauszufinden, ob es sich um ein Hardware- oder Softwareproblem handelt. Manchmal liegt beides vor, aber zunächst sollten Sie davon ausgehen, dass dies nicht der Fall ist.
Meiner Erfahrung nach ist der effektivste Weg, herauszufinden, welches Lager schuld ist, ein zweites, völlig anderes Betriebssystem zu starten (ohne die Hardware zu ändern, wohlgemerkt) und zu versuchen, das Problem zu reproduzieren. Am besten verwenden Sie ein Betriebssystem, das nicht verwendetbeliebigmit demselben Code wie das verdächtige Betriebssystem. Wenn Ihr verdächtiges System beispielsweise unter Windows läuft, können Sie Ubuntu als Testbetriebssystem verwenden. Live-CDs eignen sich hierfür gut.
Bei sporadisch auftretenden Problemen kann dies eine Herausforderung darstellen. Wie auch immer Sie vorgehen, Sie müssen wissen, ob:
- Beide Betriebssysteme sind betroffen, d. h. Sie haben ein Hardwareproblem, oder
Nur das verdächtige Betriebssystem ist betroffen. Das bedeutet, dass bei Ihnen möglicherweise Folgendes vorliegt:
- Ein Softwareproblem oder
- Eine Inkompatibilität zwischen einer Hardwarekomponente und bestimmter Software (bei der es sich fast immer um einen Treiber eines Drittanbieters handelt).
Wenn Sie denken, dass es Hardware ist
Sie haben bereits viele Komponenten getestet und ausgetauscht. Wenn das unerwünschte Verhalten in Ihrem Testbetriebssystem auftritt, verfügen Sie über schlüssige Beweise dafür, dass etwas, das Sie noch nicht ausgetauscht haben, schuld ist. Bei den Komponenten, die sich nicht für umfassende Tests eignen (z. B. das Motherboard), möchten Sie wahrscheinlich zuerst versuchen, andere, weniger kostspielige Komponenten auszutauschen. Irgendwann bleibt Ihnen jedoch möglicherweise keine andere Wahl, als auch die teureren Komponenten auszutauschen.
Wenn Sie denken, es ist Software
Wenn das Testbetriebssystem den Fehler nicht auslöst, können Sie davon ausgehen, dass ein Problem mit der Software in Ihrem Zielbetriebssystem vorliegt. Wenn der Fehler jedoch in der Vergangenheit nicht auf Anforderung erzeugt werden konnte oder anderweitig nur zeitweise auftritt, besteht immer noch die Möglichkeit, dass es sich um ein Hardwareproblem handelt, das im Testbetriebssystem einfach nicht ausgelöst wurde. Machen Sie sich keine Gedanken darüber; behalten Sie es einfach im Hinterkopf, wenn Sie Ihre vorläufigen Lösungen testen.
Wenn Sie herausfinden möchten, welcher Code fehlerhaft ist, möchten Sie natürlich bestimmte Fehlermeldungen verfolgen, z. B. die Fehlerprüfcodes von Windows, Fehler, die in den Ereignisprotokollen oder in anwendungsspezifischen Protokollen protokolliert werden. Ich überspringe diese Schritte, da ich davon ausgehe, dass Sie diese Hinweise bereits ausgeschöpft haben und einen allgemeineren Ansatz benötigen.
Wenn unklar ist, welche Software den Fehler verursacht, ist Ihre Waffe der Wahl:Entfernen Sie die Software aus der Gleichungund lassen Sie das System lange genug laufen, damit das Problem auftreten kann, falls es auftritt. Sie können dies folgendermaßen tun:
- Deinstallieren Sie die Software.
- Deaktivieren Sie es mit einem Tool wie Microsoft AutoRuns.
- Deaktivieren Sie es, indem Sie im abgesicherten Modus booten.
- Erstellen einer zweiten Windows-Installationohnedie betreffende Software (nützlich, wenn Sie die Software wirklich für den täglichen Gebrauch benötigen und einfach zwischen dem Modus „Testen“ und „Produktion“ wechseln möchten).
Dabei kategorisiere ich die Software des Systems gerne wie folgt und gehe die Fehlerbehebung entsprechend durch:
- Windows-eigener Code und Inbox-Treiber.Am wenigsten wahrscheinlich ist es, dass es daran schuld ist. Einfach zu bestätigen, indem man das System mit einer makellosen Installation testet (eine ohnebeliebigCode von Drittanbietern).
- Treiber von Drittanbietern.Verursacht immer Probleme. Stürzt normalerweise nicht zufällig ab, sodass ein Muster entsteht. Testen Sie, indem Sie verschiedene Treiberversionen verwenden oder Hardwarekomponenten austauschen.
- Software von Drittanbietern auf Systemebene(z. B. Sicherheitssoftware). Problematisch. Diese werden für den ordnungsgemäßen Systembetrieb nur selten benötigt und können vollständig deinstalliert werden, um ihren Einfluss zu testen.
- Benutzeranwendungen.Sehr unterschiedliches Absturzverhalten. Bei modernen Windows-Versionen kommt es selten zu Abstürzen oder zum Blockieren des gesamten Systems. Fehler treten nur auf, wenn die Anwendung ausgeführt wird. Daher ist es einfach, Fehler zu verfolgen und sie mit Programmen zu korrelieren, die zu diesem Zeitpunkt ausgeführt wurden. Achten Sie auf Benutzeranwendungen, die eine ständig aktive Komponente wie Startelemente oder Systemdienste haben.
Führen Sie ein halbdetailliertes Arbeitsprotokoll
Letzter Gedanke hier. Führen Sie ein Protokoll über die Probleme, auf die Sie stoßen, und die Schritte, die Sie zur Fehlerbehebung unternehmen. Bei einem schwierigen und langwierigen Problem wie diesem vergisst man leicht Einzelheiten. Wenn Sie dies während der Arbeit überprüfen können, können Sie möglicherweise Ursachen ausschließen oder Zusammenhänge zwischen Fakten herstellen, die sonst im Kampf verloren gehen könnten.
Anekdotische Geschichte
Ich habe an einem System gearbeitet, das mich an Ihre Situation erinnert. Es war ein Laptop (der meine Möglichkeiten zum Austauschen von Hardware einschränkte), der sich zufällig aufhängte. Das passierte 10 Sekunden nach dem Einschalten, dann tagelang nicht und dann nach stundenlangem Einschalten. Ich habe alles aktualisiert, jede Hardwarekomponente getestet und ausgetauscht, die ich konnte, und Windows neu installiert (mindestens einmal, wenn nicht zweimal).
Letztendlich lag es am Motherboard. Nach dem Austausch lief der Laptop viele Jahre lang ohne weitere Probleme.