Konstante BSODs innerhalb der letzten drei Tage auf einem Windows 8.1. Minidumps analysieren benötigt

-1

Kürzlich habe ich angefangen, konstante BSODs (wie BAD_POOL_HEADER, gefolgt von DRIVER_OVERRAN_STACK_BUFFER und jetzt SYSTEM_SERVICE_EXCEPTION) zu bekommen, während ich an meinen eigenen Sachen arbeitete (grundlegende Microsoft Office-Programme / normales Browsen / Programmieren). Es gab einmal, als es keinen blauen Bildschirm gab, sondern stattdessen ein festgefahrener Bildschirm. Die einzige Möglichkeit, dies zu beheben, bestand darin, einen Neustart meines Laptops zu erzwingen.

Jemand schlug mir vor, das von Windows selbst bereitgestellte Speicherdiagnosetool zu verwenden, um festzustellen, ob ein Hardwareproblem vorliegt. In dem Bericht wurde jedoch angegeben, dass der Speicher in Ordnung ist. Ich habe es auch versucht, sfc /scannowaber es gab keine Integritätsverletzungen. Versucht, alle Treiber früher zu aktualisieren, aber der Fehler tritt immer noch auf.

  • Möglicherweise versuche ich, eine Neuinstallation von Windows durchzuführen und zu prüfen, ob das Problem dadurch behoben wird. Ich bin mir nicht sicher, ob das funktionieren würde.

Ich habe versucht, den neuesten Minidump zu analysieren, und es zeigt dies. (Ich habe die vorherigen versehentlich gelöscht, während ich eine Systemprüfung durchgeführt habe):

Windows 8 Kernel Version 9600 MP (4 Prozesse) Kostenlos x64
Produkt: WinNt, Suite: TerminalServer SingleUserTS Personal
Erstellt von: 9600.18090.amd64fre.winblue_ltsb.151014-0600
Maschinenname:
Kernel base = 0xfffff803`0f47a000 PsLoadedModuleList = 0xfffff803`0f74e630
Debugsitzungszeit: Montag, 23. November, 07:55:58:47 (UTC - 5:00)
Systemverfügbarkeit: 0 Tage 7: 20: 06.694
*************************************************** ******************************
* *
* Bugcheck-Analyse *
* *
*************************************************** ******************************

SYSTEM_SERVICE_EXCEPTION (3b)
Beim Ausführen einer Systemdienstroutine ist eine Ausnahme eingetreten.
Argumente:
Arg1: 00000000c0000005, Ausnahmecode, der die Fehlerüberprüfung verursacht hat
Arg2: fffff8030f4d4d68, Adresse des Befehls, der den Bugcheck verursacht hat
Arg3: ffffd000c144d700, Adresse des Kontextdatensatzes für die Ausnahme, die die Fehlerprüfung verursacht hat
Arg4: 0000000000000000, Null.

Debugging-Details:
------------------

TRIAGER: Die Triage-Datei konnte nicht geöffnet werden: e: \ dump_analysis \ program \ triage \ modclass.ini, Fehler 2

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Der Befehl bei "0x% 08lx" verwies auf den Speicher bei "0x% 08lx". Der Speicher konnte nicht "% s" sein.

FAULTING_IP: 
nt! ObReferenceObjectSafeWithTag + c
fffff803`0f4d4d68 498b02 mov rax, qword ptr [r10]

KONTEXT: ffffd000c144d700 - (.cxr 0xffffd000c144d700)
rax = ffffe000b7666080 rbx = 790b845bb249fcc8 rcx = 790b845bb249f640
rdx = 000000006e457350 rsi = ffffe000b79c7700 rdi = 790b845bb249f640
rip = fffff8030f4d4d68 rsp = ffffd000c144e130 rbp = ffffd000c144eb80
 r8 = 0000000000000000 r9 = 7fffe000b7af4348 r10 = 790b845bb249f610
r11 = 7ffffffffffffffc r12 = ffffe000b7af44f0 r13 = 0000000000000011
r14 = ffffe000b7af4348 r15 = 0000000000000000
iopl = 0 nv up ei ng nz na po nc
cs = 0010 ss = 0018 ds = 002b es = 002b fs = 0053 gs = 002b efl = 00010286
nt! ObReferenceObjectSafeWithTag + 0xc:
fffff803`0f4d4d68 498b02 mov rax, qword ptr [r10] ds: 002b: 790b845b`b249f610 = ?????????????????
Zurücksetzen des Standardbereichs

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: vmware-authd.e

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: von fffff8030f822892 bis fffff8030f4d4d68

STACK_TEXT:  
ffffd000`c144e130 fffff803`0f822892: ffffd000`c144eb80 00000000`00000000 ffffe000`b7af4348 00000000`00000000: nt! ObReferenceObjectSafeWithTag + 0xc
ffffd000`c144e160 fffff803`0f83f041: 00000000`000080 ffffd000`0002dc90 00000000`00000000 00000000`00000000: nt! ExpGetProcessInformation + 0x432
ffffd000`c144e400 fffff803`0f83e679: 00000000`029b0090 00000000`00000004 00000000`00000005 ffffffff`fd050f80: nt! ExpQuerySystemInformation + 0x975
ffffd000`c144eac0 fffff803`0f5d40b3: ffffe000`b79c7700 00000000`00000000 ffffd000`c144ead8 ffffe000`b79c96d0: nt! NtQuerySystemInformation + 0x49
ffffd000`c144eb00 00007fff`1c8b153a: 00000000`00000000 00000000`00000000 000000000000 00000000`0000000000: nt! KiSystemServiceCopyEnd + 0x13
00000000`02cae2b8 00000000`00000000: 00000000`00000000 00000000`000000 00000000`00000000 00000000`00000000: 0x7fff`1c8b153a


FOLLOWUP_IP: 
nt! ObReferenceObjectSafeWithTag + c
fffff803`0f4d4d68 498b02 mov rax, qword ptr [r10]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt! ObReferenceObjectSafeWithTag + c

FOLLOWUP_NAME: Maschinenbesitzer

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 561e5da4

STACK_COMMAND: .cxr 0xffffd000c144d700; kb

FAILURE_BUCKET_ID: X64_0x3B_nt! ObReferenceObjectSafeWithTag + c

BUCKET_ID: X64_0x3B_nt! ObReferenceObjectSafeWithTag + c

Follow-up: Maschinenbesitzer
---------

Ich habe mich gefragt, ob jemand helfen könnte, den Minidump weiter oben zu analysieren und die Grundursache zu identifizieren. Ich vermute, dass es einige Probleme mit meiner Hardware gibt. (Ich kann sie jedoch nicht entfernen, da es sich um ein Ultrabook handelt. Muss möglicherweise in einen Laden gebracht werden.)

Hier ist die Originaldatei des Minidumps: https://www.dropbox.com/s/ypdvzwma9nlztg7/112315-4468-01.dmp?dl=0

UPDATE Ich habe die VMWare deinstalliert. Habe gerade ein weiteres BSOD erhalten, diesmal DRIVER_IRQL_NOT_LESS_OR_EQUAL.

Windows 8 Kernel Version 9600 MP (4 Prozesse) Kostenlos x64
Produkt: WinNt, Suite: TerminalServer SingleUserTS Personal
Erstellt von: 9600.18090.amd64fre.winblue_ltsb.151014-0600
Maschinenname:
Kernel base = 0xfffff802`85212000 PsLoadedModuleList = 0xfffff802`854e6630
Debugsitzungszeit: Montag, 23. November, 23: 54: 12.110 2015 (UTC - 5:00)
Systemverfügbarkeit: 0 Tage 15: 24: 23.957
*************************************************** ******************************
* *
* Bugcheck-Analyse *
* *
*************************************************** ******************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Es wurde versucht, auf eine pageable (oder vollständig ungültige) Adresse unter a zuzugreifen
IRQL (Interrupt Request Level) ist zu hoch. Das ist normalerweise so
verursacht durch Fahrer, die falsche Adressen verwenden.
Wenn der Kernel-Debugger verfügbar ist, holen Sie sich den Stack-Backtrace.
Argumente:
Arg1: fffff802107d6340, Speicher referenziert
Arg2: 000000000000000d, IRQL
Arg3: 0000000000000008, Wert 0 = Leseoperation, 1 = Schreiboperation
Arg4: fffff802107d6340, Adresse, die auf den Speicher verwiesen hat

Debugging-Details:
------------------

TRIAGER: Die Triage-Datei konnte nicht geöffnet werden: e: \ dump_analysis \ program \ triage \ modclass.ini, Fehler 2

READ_ADDRESS: fffff802854d4020: Spezielle Poolinformationen können nicht abgerufen werden
fffff802854d4020: Spezielle Poolinformationen können nicht abgerufen werden
kann nt! MmNonPagedPoolStart nicht abrufen
kann nt! MmSizeOfNonPagedPoolInBytes nicht abrufen
 fffff802107d6340 

CURRENT_IRQL: d

FAULTING_IP: 
+0
fffff802`107d6340 ?? ???

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

TRAP_FRAME: ffffd001f8cfe930 - (.trap 0xffffd001f8cfe930)
HINWEIS: Der Trap-Frame enthält nicht alle Register.
Einige Registerwerte sind möglicherweise auf Null gesetzt oder falsch.
rax = 0000000000000001 rbx = 0000000000000000 rcx = fffff802859f4e00
rdx = 000027ef00000000 rsi = 0000000000000000 rdi = 00000000000000
rip = fffff802107d6340 rsp = ffffd001f8cfeac8 rbp = ffffd001f8cfeb50
 r8 = 00000000002048c6 r9 = fffff80285512f80 r10 = 0000000000000001
r11 = fffff8028556f910 r12 = 0000000000000000 r13 = 0000000000000000
r14 = 0000000000000000 r15 = 0000000000000000
iopl = 0 nv up di ng nz na pe nc
fffff802`107d6340 ?? ???
Zurücksetzen des Standardbereichs

LAST_CONTROL_TRANSFER: von fffff8028536c3e9 bis fffff802853608a0

FAILED_INSTRUCTION_ADDRESS: 
+0
fffff802`107d6340 ?? ???

STACK_TEXT:  
ffffd001`f8cfe7e8 fffff802`8536c3e9: 00000000`0000000a fffff802`107d6340 00000000`0000000d 00000000`00000008: nt! KeBugCheckEx
ffffd001`f8cfe7f0 fffff802`8536ac3a: 00000000`00000008 ffffd001`f8cea180 00000000`20000000 ffffd001`f8cfeaf8: nt! KiBugCheckDispatch + 0x69
ffffd001`f8cfe930 fffff802`107d6340: fffff802`8536211c ffffe001`3c37a000 00000000`00000001 ffffe001`3c37a000: nt! KiPageFault + 0x23a
ffffd001`f8cfeac8 fffff802`8536211c: ffffe001`3c37a000 00000000`00000001 ffffe001`3c37a000 ffffd001`f8cea180: 0xfffff802`107d6340
ffffd001`f8cfead0 fffff802`853643c2: ffffd001`f8cea180 ffffd001`f8cea180 ffffd001`f8cf62c0 00000000`00000001: nt! KiInterruptDispatchLBControl + 0x12c
ffffd001`f8cfec60 00000000`00000000: ffffd001`f8cff000 ffffd001`f8cf9000 00000000`00000000 00000000`00000000: nt! KiIdleLoop + 0x32


STACK_COMMAND: kb

FOLLOWUP_IP: 
zt! KiPageFault + 23a
fffff802`8536ac3a 440f20c0 mov rax, cr8

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt! KiPageFault + 23a

FOLLOWUP_NAME: Maschinenbesitzer

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 561e5da4

FAILURE_BUCKET_ID: X64_AV_CODE_AV_BAD_IP_nt! KiPageFault + 23a

BUCKET_ID: X64_AV_CODE_AV_BAD_IP_nt! KiPageFault + 23a

Follow-up: Maschinenbesitzer
---------

Minidump-Link: https://www.dropbox.com/s/udf9ke81gt3bkce/112415-4421-01.dmp?dl=0

Mein Laptop war stundenlang im Akkubetrieb, bis ich mich entschied, ihn durch Einstecken des Adapters aufzuladen. Nach ca. 10 Minuten trat der BSOD auf. Könnte dies stattdessen an meinem Adapter liegen? Ich erinnere mich gerade, dass es vor ein paar Tagen einen Blitzeinschlag gegeben hat und ein Funke vom Ladeloch des Laptops zu sehen war, während der Adapter eingesteckt war. (Die Steckdose war aber nicht an.)

UPDATE (nochmal). Habe gerade einen schnellen memtest86 + über eine Stunde lang durchgeführt. Es gab zwei fehlerfreie Durchläufe in beiden RAM-Steckplätzen (jeweils 2 GB). Habe einen Festplattenfehler überprüft und keine Fehler gefunden.

UPDATE IRQL_NOT_LESS_OR_EQUALs Minidump-Analyse:

Windows 8 Kernel Version 9600 MP (4 Prozesse) Kostenlos x64
Produkt: WinNt, Suite: TerminalServer SingleUserTS Personal
Erstellt von: 9600.18090.amd64fre.winblue_ltsb.151014-0600
Maschinenname:
Kernel base = 0xfffff800`30478000 PsLoadedModuleList = 0xfffff800`3074c630
Debug-Sitzungszeit: Di., 24. November, 02:16:20:080 (UTC - 5:00)
Systemverfügbarkeit: 0 Tage 0: 11: 11.927
*************************************************** ******************************
* *
* Bugcheck-Analyse *
* *
*************************************************** ******************************

IRQL_NOT_LESS_OR_EQUAL (a)
Es wurde versucht, auf eine pageable (oder vollständig ungültige) Adresse unter a zuzugreifen
IRQL (Interrupt Request Level) ist zu hoch. Das ist normalerweise so
verursacht durch Fahrer, die falsche Adressen verwenden.
Wenn ein Kernel-Debugger verfügbar ist, holen Sie sich den Stack-Backtrace.
Argumente:
Arg1: 0000000000000007, Speicher referenziert
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, Bitfeld:
    Bit 0: Wert 0 = Leseoperation, 1 = Schreiboperation
    Bit 3: Wert 0 = keine Ausführungsoperation, 1 = Ausführungsoperation (nur für Chips, die diese Statusstufe unterstützen)
Arg4: fffff800304e5622, Adresse, die auf den Speicher verwiesen hat

Debugging-Details:
------------------

TRIAGER: Die Triage-Datei konnte nicht geöffnet werden: e: \ dump_analysis \ program \ triage \ modclass.ini, Fehler 2

READ_ADDRESS: fffff8003073a020: Spezielle Poolinformationen können nicht abgerufen werden
fffff8003073a020: Spezielle Poolinformationen können nicht abgerufen werden
kann nt! MmNonPagedPoolStart nicht abrufen
kann nt! MmSizeOfNonPagedPoolInBytes nicht abrufen
 0000000000000007 

CURRENT_IRQL: 2

FAULTING_IP: 
zt! MiInsertAndUnlockStandbyPages + 186
fffff800`304e5622 448a4558 mov r8b, byte ptr [rbp + 58h]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: svchost.exe

TRAP_FRAME: ffffd001be7743f0 - (.trap 0xffffd001be7743f0)
HINWEIS: Der Trap-Frame enthält nicht alle Register.
Einige Registerwerte sind möglicherweise auf Null gesetzt oder falsch.
rax = ffffd001be774540 rbx = 0000000000000000 rcx = ffffd001be774540
rdx = fffffa8002677c80 rsi = 0000000000000000 rdi = 0000000000000000
rip = fffff800304e5622 rsp = ffffd001be774580 rbp = ffffd001be7745d0
 r8 = 000000c000000000 r9 = fffffa8001ce28b0 r10 = 000000000009a0d9
r11 = 000000000000000f r12 = 0000000000000000 r13 = 0000000000000000
r14 = 0000000000000000 r15 = 0000000000000000
iopl = 0 nv up ei pl zr na po nc
zt! MiInsertAndUnlockStandbyPages + 0x186:
fffff800`304e5622 448a4558 mov r8b, Byte ptr [rbp + 58h] ss: ffffd001`be774628 = 02
Zurücksetzen des Standardbereichs

LAST_CONTROL_TRANSFER: von fffff800305d23e9 zu fffff800305c68a0

STACK_TEXT:  
ffffd001`be7742a8 fffff800`305d23e9: 00000000`0000000a 00000000`00000007 00000000`00000002 00000000`00000000: nt! KeBugCheckEx
ffffd001`be7742b0 fffff800`305d0c3a: 00000000`000000 00000000`00000000 ffffd001`be774400 ffffd001`00000001: nt! KiBugCheckDispatch + 0x69
ffffd001`be7743f0 fffff800`304e5622: 00000000`00000000 ffffd001`be7746f0 00000000`00000007 fffffa80`029334f0: nt! KiPageFault + 0x23a
ffffd001`be774580 fffff800`304e4397: 00000000`00000000 00000000`000000 ffffe001`a9c2e760 00000168`424e6f02: nt! MiInsertAndUnlockStandbyPages + 0x186
ffffd001`be774610 fffff800`304e3d31: 00000000`00000000 ffffd001`be7748f8 ffffe001`abc77a98 00000000`00000000: nt! MiFinishHardFault + 0x497
ffffd001`be774790 fffff800`304e5dec: 00000000`00000003 ffffd001`be7748f8 ffffe001`abc77a98 ffffd001`00000000: nt! MiWaitForInPageComplete + 0x27d
ffffd001`be774880 fffff800`304cf91a: ffffe001`abc77a98 ffffe001`ad9ee880 00000000`00000000 ffffd001`be7749f0: nt! MiIssueHardFault + 0x184
ffffd001`be774940 fffff800`305d0b2f: 00000000`00000000 00000000`00000000 00000067`da280701 00007fff`5bab4950: nt! MmAccessFault + 0x5ba
ffffd001`be774b00 00007fff`5b80ecae: 00000000`00000000 00000000`000000 00000000`000000 00000000`00000000: nt! KiPageFault + 0x12f
00000067`da3fe940 00000000`00000000: 00000000`00000000 00000000`000000 00000000`00000000 00000000`000000: 0x7fff`5b80ecae


STACK_COMMAND: kb

FOLLOWUP_IP: 
zt! MiInsertAndUnlockStandbyPages + 186
fffff800`304e5622 448a4558 mov r8b, byte ptr [rbp + 58h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt! MiInsertAndUnlockStandbyPages + 186

FOLLOWUP_NAME: Maschinenbesitzer

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 561e5da4

IMAGE_NAME: Speicherbeschädigung

FAILURE_BUCKET_ID: X64_AV_nt! MiInsertAndUnlockStandbyPages + 186

BUCKET_ID: X64_AV_nt! MiInsertAndUnlockStandbyPages + 186

Follow-up: Maschinenbesitzer
---------

Meine Systemspezifikationen:
Betriebssystem: Windows 8.1 64-Bit;
Prozessor: Intel Core i5 4200U bei 1,60 GHz;
RAM: 4,00 GB Zweikanal-DDR3 bei 798 MHz;
Hauptplatine: SAMSUNG ELECTRONICS CO., LTD. NP940X3G-K06US (BUCHSE 0);
Grafik: Allgemeiner PnP-Monitor (1600 x 900 bei 60 Hz) und Intel HD-Grafikfamilie (Samsung);
Speicher: 119 GB TOSHIBA THNSNH128G8NT (SSD);
Keine optischen Laufwerke.

Jede Hilfe wird sehr geschätzt! Vielen Dank.

windows-8.1  64-bit  bsod  troubleshooting  minidumps 
— Jay Lim
quelle
Ihre Probleme werden durch VMWare verursacht.
— Ramhound
@Ramhound, bedeutet das, dass es Probleme mit meinen Host-Treibern gibt? Übrigens gab es keine virtuellen Maschinen auf meinem Hintergrund (außer der VMWare Workstation)
— Jay Lim
Sie haben die Anzahl der möglichen Ursachen für uns nicht eingegrenzt, daher kann ich nicht sagen, ob es sich um ein Treiberproblem handelt, aber der Prozess, der den Absturz verursacht hat, gehörte zu einem VMWare-Produkt.
— Ramhound
@ Ramhound vielen Dank für Ihr Feedback! Ich habe die VMWare deinstalliert, aber jetzt tritt ein anderer Fehler auf. Es sieht so aus, als ob es jetzt mit dem Systemprozess zusammenhängt.
— Jay Lim
Führen Sie memtest86 + aus, um RAM-Fehler zu erkennen.
— magicandre1981

Antworten:

-1

Stellen Sie sicher, dass alle Treiber auf dem neuesten Stand sind, insbesondere der GPU- Treiber. Gelingt dies nicht, ist meiner Meinung nach eine Neuinstallation von Windows der nächste Schritt bei der Lösung Ihrer BSODs. Wenn die Windows-Neuinstallation dies nicht behebt, liegt höchstwahrscheinlich ein Hardwareproblem vor.

— Bilfred
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.