Anzeige

Am Puls von Microsoft

Anzeige

System Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

@Porky

So, Firmware ist aktualisiert. Ich werde mich wohl nie an die ganze DOS Geschichte gewöhnen. Das macht mich furchtbar nervös ^^"

@Silver Server

Ich mein, ich kann das ding wieder über Nacht laufen lassen. Gibt es sowas auch für Laufwerke? Oder kann man aus den DMPs irgenwie herauslesen welcher Speicher denn da genau den Fehler hatte?

Nachtrag zum Nachtrag:

Hast Du das mit dem andren Speichertakt probiert?

Habe ich nicht, weil ich im BIOS nichts dazu gefunden habe. Und UEFI findet kein Betriebssystem.
 
Anzeige
Bei den Festplatten kannst Du nur die SMART Werte mit CrystalDiskInfo auslesen.

Und nein ich kann aus der Dumpfile nicht auslesen welcher Speicher betroffen ist.
Ich kann nur sagen, es liegt im Bereich der Festplatte oder des Arbeitsspeicher.
 
Wenn dein Samsung Magician noch eine Performance Restauration Funktion hat (hieß so in den alten Versionen), dann lasse das einmal durchlaufen. Danach kümmert sich die neue Firmware um die Auffrischung der Speicherzellen. Tut sie zwar auch so, aber nur dezent im Hintergrund, so dass das einige Stunden oder Tage (keine Ahnung) dauern kann.
 
STACK_TEXT:
ffffd000`23a86678 fffff801`0dc50741 : 00000000`0000001a 00000000`00041287 000000e9`f38b6000 00000000`00000000 : nt!KeBugCheckEx
ffffd000`23a86680 fffff801`0dd52b9d : 000000e9`f38b6000 00000000`00000000 00000000`00000000 00000000`00000002 : nt!MmAccessFault+0x9a1
Es entstand ein Zugriffs Fehler
ffffd000`23a86780 fffff801`0dc64b81 : 00000000`00012017 ffffd000`23a86988 ffffe001`69a62e50 ffffe001`7244f610 : nt!KiPageFault+0x31d
das war ein Seitenfehler
ffffd000`23a86910 fffff801`0ddeae0b : 00000000`c0000016 00000000`c0000016 ffffd000`23a86b00 00000000`00000580 : nt!MiCheckUserVirtualAddress+0x81
Die Virtuelle Adresse wurde überprüft
ffffd000`23a86940 fffff801`0dc50194 : 00000000`c0000016 00000000`00000001 ffffd000`23a86aa0 ffffd000`23a86a40 : nt!MiZeroFault+0xc3
Es wurde ein Null Fehler ermittelt
ffffd000`23a86a00 fffff801`0dd52b9d : 000000e9`f978adec 000000e9`ec7f2900 00000000`00000001 000000e9`ee144480 : nt!MmAccessFault+0x3f4
ffffd000`23a86b00 00007ffb`a700690e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x31d
000000e9`f304f2a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`a700690e

SYMBOL_NAME: nt!KiPageFault+31d
Ich interpretiere das so das ein Fehler durch den Virtuellen Speicher entstanden ist. Der Virtuelle Speicher wird benutzt wenn der Arbeitsspeicher Inhalte auf die Festplatte auslagert. Es ist also sowohl der Arbeitsspeicher als auch die Festplatte beteiligt.
 
An dieser Stelle muss ich mein Aussage etwas korrigieren.
Ich dachte der Virtuelle Speicher ist die Auslagerungsdatei. Das ist so nicht richtig . Die Auslagerungsdatei ist genau so wie der RAM ein physischer Speicher. Dein Virtueller Speicher ist ein Prozessspeicher. Die Umsetzung der virtuellen Adresse in eine physikalische Adresse übernimmt die Memory Management Unit. Das heißt der Virtuelle Speicher befindet sich nicht im Arbeitsspeicher und auch nicht auf der Festplatte. Das ist ein Systemvorgang.

Wer es besser wissen will wie ich es erklären kann, sollte es sich selber anlesen. Hier ein Anfang dazu von Wikipedia https://de.wikipedia.org/wiki/Virtuelle_Speicherverwaltung
 
Womöglich finales Update:

der letzte BSOD ist jetzt drei Tage her. Drei Tage an denen ich meinen Laptop so intensiv genutzt habe, wie damals mit Windows 7.

Porky's Lösung scheint das Problem gelöst zu haben:
SSD-Firmware Updaten!

Zusätzlich noch eine kleine Sidestory von dem ganzen Problem: Während der ganzen Zeit hatte ich immer wieder mit abstürzenden Browsertabs zu kämpfen. Meistens unvorhergesehen und auf unterschiedlichsten Seiten. Seit dem Firmwareupdate der SSD sind die genauso verschwunden, wie die Bluescreens.

Ich vermute es war eine Kombination aus dem BIOS-Update und dem SSD-Firmware-Update, die das Problem behoben haben.

Vorsichtshalber würde ich den Thread gerne bis Sonntag den 02.02.2020 offen lassen. Danach betrachte ich das Problem offiziell als gelöst und werde den Thread entsprechend markieren.

Ich möchte mich aber jetzt schon bei euch allen für eure Hilfe bedanken! Ihr habt meinen Laptop vor einem Gratisflug vom Balkon bewahrt :)
 
Hallo @Quintus!
Bei deinem letzten Bluescreen ist ein Systemservice abgestürzt.
SYSTEM_SERVICE_EXCEPTION (3b)
Und das war der Auslöser
FAILURE_BUCKET_ID: 0x3B_c0000005_win32k!ClientGetMessageMPH
Zuerst die Auszüge aus dem Debugger-Log
Code:
[COLOR="#008000"]// der letzte Thread [/COLOR]
!thread
THREAD ffffe000d31b4080  Cid 1e20.0724  Teb: 00007ff6c0d8c000 Win32Thread: fffff9014063db50 RUNNING on processor 2
Not impersonating
GetUlongFromAddress: unable to read from fffff800afaaeb70
Owning Process            ffffe000d44b8080       Image:         explorer.exe
Attached Process          N/A            Image:         N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount      24207429     
Context Switch Count      81914          IdealProcessor: 7             
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address 0x00007ff8958255f0
Stack Init ffffd0002335fc90 Current ffffd0002335efd0
Base ffffd00023360000 Limit ffffd0002335a000 Call 0000000000000000
Priority 12 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
...
[COLOR="#008000"]// und hier der Stack des Prozesses[/COLOR]
# Child-SP          RetAddr           Call Site
00 ffffd000`2335f830 fffff800`afbdd463 nt!MmCreateKernelStack+0x321
01 ffffd000`2335f8d0 fffff960`00249154 nt!KeUserModeCallback+0xa3
02 ffffd000`2335f970 fffff960`000d91c8 win32k!ClientGetMessageMPH+0x74
03 ffffd000`2335f9e0 fffff960`000f35c2 win32k!xxxInternalGetMessage+0x38
04 ffffd000`2335fa20 fffff800`af9633e3 win32k!NtUserPeekMessage+0x82
05 ffffd000`2335fa90 00007ff8`9a3a2aca nt!KiSystemServiceCopyEnd+0x13
06 00000000`0452fb68 00000000`00000000 0x00007ff8`9a3a2aca
...
[COLOR="#008000"]// und der zugehörige Context-Record[/COLOR]
CONTEXT:  ffffd0002335ee10 -- (.cxr 0xffffd0002335ee10)
rax=0000000000000000 rbx=80000003453ac863 rcx=fffffa8009cfb040
rdx=ffffd00023e8f010 rsi=fffffa8009cfb040 rdi=fffff6e80011f448
rip=fffff800af864091 rsp=ffffd0002335f830 rbp=0000000000000000
 r8=ffffd00023e8f010  r9=559f8dd488a1db1d r10=fffffa80188fd870
r11=ffffd0002335f9d8 r12=ffffd00023e90000 r13=0000000000000006
r14=0000000000000006 r15=ffffe000d31b4081
iopl=0         nv up ei ng nz na pe cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010283
nt!MmCreateKernelStack+0x321:
fffff800`af864091 8b05eddf2f00    mov     eax,dword ptr [nt!PerfGlobalGroupMask+0x4 (fffff800`afb62084)] [COLOR="#FF0000"]ds:002b:fffff800`afb62084=????????[/COLOR]

Auswertung:
bei Stack #04 generiert win32k.sys eine Nachricht
bei Stack #02 wird die Nachricht weiter geleitet
bei Stack #00 wird der Kernel beauftragt, einen Kernel-Stack zu installieren
Der nächste Schritt ist
fffd000`2335f6a0 fffff800`af864091 : nt!KiPageFault+0x402 (TrapFrame @ ffffd000`2335f6a0)
Also ein Speicher-Seitenfehler.
Was ist bei der Übergabe passiert?
Code:
.trap ffffd000`2335f6a0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8009cfb040
rdx=ffffd00023e8f010 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800af864091 rsp=ffffd0002335f830 rbp=0000000000000000
 r8=ffffd00023e8f010  r9=559f8dd488a1db1d r10=fffffa80188fd870
r11=ffffd0002335f9d8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe cy
[COLOR="#FF0000"]nt!MmCreateKernelStack+0x321:
fffff800`af864091 8b05eddf2f00    mov     eax,dword ptr [nt!PerfGlobalGroupMask+0x4 (fffff800`afb62084)] ds:fffff800`afb62084=????????[/COLOR]
Mit mov soll das Datensegment von nt!PerfGlobalGroupMask+0x4 nach dem Register eax verschoben werden.
Dabei muss es zur Zugriffsverletzung (0xc0000005) kommen, weil das Datensegment nur Datenmüll enthält.
ds:fffff800`afb62084=????????

Allerdings lässt sich mit dieser Dumpfile nicht ermitteln, wer das Datensegment von nt!PerfGlobalGroupMask zerstört hat.
Im Zweifelsfall war es das Spiel, das da gerade lief.
 
Das Spiel, das ich zu dem Zeitpunk offen hatte war Old School Runescape.

Ich werde es mal deinstallieren und ein anderes offen lassen, um zu testen ob es das war.
 
Nabend Leute,

bin mal wieder da, mit zwei komplett neuen Crashes. Weiterhin ntoskrnl dabei:

Welche Software nutzt ihr eigentlich um die Teile auszulesen/herauszufinden, welches Programm oder Treiber zuletzt aktiv war? Vielleicht sollte ich mir das Mal antrainieren.

Hier die Dumps:

Anhang anzeigen DMP 13.02.2020.zip
 
Filde 021220-24781-01.dmp
SYMBOL_NAME: NETwew00+1ee979

MODULE_NAME: NETwew00

IMAGE_NAME: NETwew00.sys

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 1ee979

FAILURE_BUCKET_ID: 0x1E_c0000005_R_STACKPTR_ERROR_NETwew00!unknown_function
Der Treiber des Wireless WiFi Link Adapter hat den Fehler ausgelöst.

---------------------

File 021320-21375-01.dmp

RVPOWERSTATE_SUBCODE: 3

IMAGE_NAME: usbhub.sys

MODULE_NAME: usbhub

FAULTING_MODULE: fffff80154200000 usbhub

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System
Der Standardhubtreiber für USB Treiber hat hier den Fehler ausgelöst.

_______________________________________________

Hier findest Du erste Informationen wie man die Dumpfile auswertet.
https://www.informationsarchiv.net/articles/2179/
 
Guten Abend zusammen! :)
Die Infgormationen aus der Dumpfile 021320-21375-01.dmp lassen sich noch etwas konkreter darstellen, denn es läßt sich ein konkreter USB-Treiber ermitteln.
Code:
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe00148843060, Physical Device Object of the stack
Arg3: ffffd0004ca74960, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffe0014b0ef810, The blocked IRP  
[COLOR="#008000"]Arg1 gibt das Objekt an, das den IRP-Stack blockiert
Arg4 ist die Adresse des IRP-Stack; damit läßt sich der Treiber ermitteln[/COLOR]
....
FAILURE_BUCKET_ID:  0x9F_3_FocusriteUSB_IMAGE_usbhub.sys
[COLOR="#008000"]Hier wird schon mal auf den möglichen Verursacher FocusriteUSB.sys hingewiesen
Der Nachweis steht noch aus[/COLOR]
....
[COLOR="#008000"]Mit Arg2 das Device-Object abfragen[/COLOR]
!devobj ffffe00148843060
Device object (ffffe00148843060) is for:
 Cannot read info offset from nt!ObpInfoMaskToOffset
 \Driver\usbhub DriverObject ffffe00148597c80
Current Irp 00000000 RefCount 1 Type 00000022 Flags 00003040
SecurityDescriptor ffffc0016d67dae0 DevExt ffffe001488431b0 DevObjExt ffffe00148843d60 DevNode ffffe0014a4b46a0 
ExtensionFlags (0000000000)  
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffe0014a4b4040 \Driver\ACPI
Device queue is not busy.
[COLOR="#008000"]Das war nichts, nur allgemein USBHub; aber mit DevNode kann weiter gegraben werden[/COLOR]
!devnode ffffe0014a4b46a0
DevNode 0xffffe0014a4b46a0 for PDO 0xffffe00148843060
  Parent 0xffffe00148bbf4f0   Sibling 0000000000   Child 0000000000   
 [COLOR="#FF0000"] InstancePath is "USB\VID_1235&PID_8016\6&330c3fed&0&5"[/COLOR]
  [COLOR="#FF0000"]ServiceName is "FocusriteUSB"[/COLOR]
[COLOR="#008000"]Hier wird es schon konkreter[/COLOR]
  TargetDeviceNotify List - f 0xffffc0016eba5120  b 0xffffc0016eba5120
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)
....
[COLOR="#008000"]Jetzt mit Arg4 den IRP-Stack abfragen[/COLOR]
!irp ffffe0014b0ef810
Irp is active with 10 stacks 9 is current (= 0xffffe0014b0efb20)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  Pending has been returned
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    
[COLOR="#008000"]// wegen der besseren Übersicht habe ich hier 6 Null-Stacks enfernt[/COLOR]
[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
            0  0 ffffe00148843060 00000000 00000000-00000000    
	       \Driver\usbhub
			Args: 00000000 00000000 00000000 00000002
.....
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
            0 e1 [COLOR="#FF0000"]ffffe0014a4b9a10[/COLOR] 00000000 fffff8012d3827fc-ffffe00147fee550 Success Error Cancel pending
	      Unable to load image \SystemRoot\System32\drivers\FocusriteUSB.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for FocusriteUSB.sys
 \Driver\FocusriteUSB	nt!PopRequestCompletion
			Args: 00051100 00000001 00000001 00000002
[COLOR="#008000"]// Hier ist jetzt klar, dass der Treiber FocusriteUSB.sys den IRP-Stack blockiert. [/COLOR]

[COLOR="#008000"]// hier ist nun Ende. Das Abfragen von classpnp!_FUNCTIONAL_DEVICE_EXTENSION mit
der rot markierten Adresse bringt keine tieferen Erkenntnisse[/COLOR]
Hier habe ich mal etwas tiefer gegraben, um den fehlerhaften Treiber aus FAILURE_BUCKET_ID zu ermitteln. Dort wurde auch der USBHub als Ursache genannt. Darauf muss man sich nicht verlassen, was im Folgenden auch bestätigt wurde.
Der wirkliche Verursacher ist der Treiber, der den IRP-Stack blockiert.
Und das war image \SystemRoot\System32\drivers\FocusriteUSB.sys

Einen IRP-Stackframe über dem blockierten Stack wartet das System darauf, aufgeweckt zu werden.

Noch eine kurze Erklärung zu den Argumenten des IRP-Stack
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
IRP-Major-Parameter = Power soll geändert werden
IRP-Minor-Parameter = Power soll neu gesetzt werden (wahrscheinlich erhöht)
Normalerweise kann man mit der rot markierten Adresse und und dem Debuggerbefehl classpnp!_FUNCTIONAL_DEVICE_EXTENSION eine sehr lange Liste mit genaueren Werten zum IRP-Stackframe und dem Gerät
ermitteln. Leider bringt das in diesem Fall nur Speichermüll.

Aber ich denke, der ware Übeltäter ist hinreichend ermittelt.
Nun kommt es darauf an, zu ermitteln, wozu dieser Treiber gehört. Er ist ja kein Treiber des Windows-Systems.
 
Anzeige
Oben