Sporadisch BSOD's Windows 8.1 x64 Pro Update 1

[Astra-G]

Hallo liebe Mitglieder,

mein PC verursacht seit letzter Woche Donnerstag immer wieder und in unregelmäßigen Abständen Bluescreens.
Meinen RAM hab ich schon auf Fehler mit Memtest getestet. Es wurden hierbei keine Fehler gefunden.
Auch Treiber oder Software habe ich seit der Zeit keine installiert, ebenso wenig die Hardware verändert.
Im DUMP steht etwas von Win 8 Driver Failure und ein paar Zeilen weiter amd64fre.
Nun wollte ich von den Experten von euch hören (die die DUMP vllt professioneller als ich lesen können), ob es sein kann, dass der AMD-Treiber auf einmal spontan das zicken anfängt? Einfach so aus dem nichts?

Ich habe euch die Analyse von WinDbg angehängt für mehr Infos.

Ich bin mit dem Rätselraten am Ende meiner Latein angekommen, leider.

Microsoft (R) Windows Debugger Version 6.3.9600.17029 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Matthias\Desktop\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Windows 8 Kernel Version 9600 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17041.amd64fre.winblue_gdr.140305-1710
Machine Name:
Kernel base = 0xfffff803`d9212000 PsLoadedModuleList = 0xfffff803`d94dc2d0
Debug session time: Mon Apr 14 20:14:45.512 2014 (UTC + 2:00)
System Uptime: 0 days 1:14:00.177
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Loading Kernel Symbols
...............................................................
............................................Page 42325a not present in the dump file. Type ".hh dbgerr004" for details
....................
....................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00007ff7`ca93d018). Type ".hh dbgerr001" for details
Loading unloaded module list
.....................

************* Symbol Loading Error Summary **************
Module name Error
ntkrnlmp The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a01f58e1eb66d3, b3b72bdf346a9d86, ffffe0004c91fed0, 1c}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Page 42325a not present in the dump file. Type ".hh dbgerr004" for details
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntkrnlmp.exe

Followup: MachineOwner
---------

7: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f58e1eb66d3, Reserved
Arg2: b3b72bdf346a9d86, Reserved
Arg3: ffffe0004c91fed0, Failure type dependent information
Arg4: 000000000000001c, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Page 42325a not present in the dump file. Type ".hh dbgerr004" for details
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff803d9212000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 5318053f

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

STACK_TEXT:
ffffd000`235b1088 00000000`00000000 : 00000000`00000109 a3a01f58`e1eb66d3 b3b72bdf`346a9d86 ffffe000`4c91fed0 : nt!KeBugCheckEx


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntkrnlmp.exe

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID: WRONG_SYMBOLS

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:wrong_symbols

FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}

Followup: MachineOwner
---------

Vllt. hilft das euch auch noch weiter.
Die folgenden Updates wurden vor den spontanen Abstürzen installiert:


Macht da eins der Updates Probleme?
Möglicherweise auch bei euch?

Vielen Dank und viele Grüße
Astra-G

 

[derlorenz]

Liegt unter C:/Windows/Minidump was aktuelles? Wenn ja bitte mal http://www.osronline.com/page.cfm?name=analyze hier hoch laden. Ist ganz praktisch, wie ich finde. Liest sich leichter denke ich, da dein dump nicht ganz debugged ist...

 

[simpel1970]

Symbol search path is: *** Invalid ***

Der Symbol Pfad ist im Debugger nicht hinterlegt!
---

Loading Dump File [C:\Users\Matthias\Desktop\MEMORY.DMP]

Die Memory Dump lässt sich leider bei OSR nicht hochladen (zu groß).

Entweder den Symbolpfad im Debugger korrekt einstellen (siehe Signatur), oder die Debuginformationen auf "kleines Speicherabbild" umstellen, damit du Minidumps erhältst, die du bei OSR Online auswerten lassen kannst.

 

[Astra-G]

Ich konnte die Datei gestern leider nicht mehr hochladen, der Rechner hat mich nicht gelassen (3 Abstürze am Stück ... )
Ich hab mit WhoCrashed nochmal die Dumps geöffnet.

Crash dump directory: C:\Windows\Minidump

Crash dumps are enabled on your computer.

On Mon 14.04.2014 20:15:25 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041414-5812-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x153FA0)
Bugcheck code: 0x109 (0xA3A01F58BCC8B8D6, 0xB3B72BDF0F47EF79, 0xFFFFE0002D122ED0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Mon 14.04.2014 20:15:25 GMT your computer crashed
crash dump file: C:\Windows\memory.dmp
This was probably caused by the following module: ntkrnlmp.exe (nt!KeBugCheckEx+0x0)
Bugcheck code: 0x109 (0xA3A01F58BCC8B8D6, 0xB3B72BDF0F47EF79, 0xFFFFE0002D122ED0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
Bug check description: This indicates that the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Mon 14.04.2014 19:42:32 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041414-5296-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x153FA0)
Bugcheck code: 0x109 (0xA3A00F58B3AFD578, 0xB3B71BDF062F0C2B, 0xFFFFE000101224E0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Mon 14.04.2014 18:39:08 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041414-6562-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x153FA0)
Bugcheck code: 0x109 (0xA3A01F5A27C8B695, 0xB3B72BE07A47ED48, 0xFFFFE00191929ED0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Mon 14.04.2014 18:19:15 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041414-5421-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x153FA0)
Bugcheck code: 0x109 (0xA3A01F592790CA76, 0xB3B72BDF7A100129, 0xFFFFE00098111ED0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Mon 14.04.2014 18:14:45 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041414-5531-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x153FA0)
Bugcheck code: 0x109 (0xA3A01F58E1EB66D3, 0xB3B72BDF346A9D86, 0xFFFFE0004C91FED0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Mon 14.04.2014 17:00:15 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041414-5390-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x153FA0)
Bugcheck code: 0x109 (0xA3A01F5A288F5667, 0xB3B72BE07B0E8D0A, 0xFFFFE00198D215D0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Sun 13.04.2014 18:21:30 GMT your computer crashed
crash dump file: C:\Windows\Minidump\041314-5890-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x14DCA0)
Bugcheck code: 0x109 (0xA3A00F58B80FAC30, 0xB3B71BDF0A8EE207, 0xFFFFE000029D35E0, 0x1C)
Error: CRITICAL_STRUCTURE_CORRUPTION
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 the kernel has detected critical kernel code or data corruption.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

Und nach Anleitung von @simpel1970

Microsoft (R) Windows Debugger Version 6.3.9600.17029 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Matthias\Desktop\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Windows 8 Kernel Version 9600 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17041.amd64fre.winblue_gdr.140305-1710
Machine Name:
Kernel base = 0xfffff802`a5a1a000 PsLoadedModuleList = 0xfffff802`a5ce42d0
Debug session time: Mon Apr 14 20:39:08.700 2014 (UTC + 2:00)
System Uptime: 0 days 0:19:25.365
Loading Kernel Symbols
...............................................................
................................................................
.......................
Loading User Symbols

Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a01f5a27c8b695, b3b72be07a47ed48, ffffe00191929ed0, 1c}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5a27c8b695, Reserved
Arg2: b3b72be07a47ed48, Reserved
Arg3: ffffe00191929ed0, Failure type dependent information
Arg4: 000000000000001c, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

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


DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

STACK_TEXT:
ffffd000`24ffe088 00000000`00000000 : 00000000`00000109 a3a01f5a`27c8b695 b3b72be0`7a47ed48 ffffe001`91929ed0 : nt!KeBugCheckEx


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

IMAGE_VERSION:

BUCKET_ID: BAD_STACK

FAILURE_BUCKET_ID: BAD_STACK

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:bad_stack

FAILURE_ID_HASH: {75814664-faf6-4b70-bbc7-dc592132ecdd}

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5a27c8b695, Reserved
Arg2: b3b72be07a47ed48, Reserved
Arg3: ffffe00191929ed0, Failure type dependent information
Arg4: 000000000000001c, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

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


DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

STACK_TEXT:
ffffd000`24ffe088 00000000`00000000 : 00000000`00000109 a3a01f5a`27c8b695 b3b72be0`7a47ed48 ffffe001`91929ed0 : nt!KeBugCheckEx


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

IMAGE_VERSION:

BUCKET_ID: BAD_STACK

FAILURE_BUCKET_ID: BAD_STACK

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:bad_stack

FAILURE_ID_HASH: {75814664-faf6-4b70-bbc7-dc592132ecdd}

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5a27c8b695, Reserved
Arg2: b3b72be07a47ed48, Reserved
Arg3: ffffe00191929ed0, Failure type dependent information
Arg4: 000000000000001c, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

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


DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

STACK_TEXT:
ffffd000`24ffe088 00000000`00000000 : 00000000`00000109 a3a01f5a`27c8b695 b3b72be0`7a47ed48 ffffe001`91929ed0 : nt!KeBugCheckEx


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

IMAGE_VERSION:

BUCKET_ID: BAD_STACK

FAILURE_BUCKET_ID: BAD_STACK

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:bad_stack

FAILURE_ID_HASH: {75814664-faf6-4b70-bbc7-dc592132ecdd}

Followup: MachineOwner
---------

Und schon mal vielen Dank für die Rückmeldungen

 

[MagicAndre1981]

schau mal hier:

Bekommt ihr den Fehler CRITICAL_STRUCTURE_CORRUPTION unter Windows 8.1?
http://www.winvistaside.de/forum/index.php?showtopic=5398

 

[Astra-G]

Danke für den Link.
Leider hab ich nichts von den drei Programmen installiert.

Echt ein komisches Phänomen ^^

 

[simpel1970]

Aktiviere den Treiber Verifier und lade die Dumps hier hoch, die vom Verifier produziert werden.
Sofern das System mit dem Verifier nicht mehr stabil laufen sollte, kannst du diesen im abgesicherten Modus mit "verifier.exe /reset" wieder deaktivieren.

http://answers.microsoft.com/en-us/...behaving/f5cb4faf-556b-4b6d-95b3-c48669e4c983

 

[Astra-G]

Guten Tag,

leider hatte ich die letzten Tage nicht die Zeit, mich um das Problem zu kümmern.
Heute habe ich es versucht.

Hier ist die DMP, die zur Verifier-Laufzeit entstanden ist.

Ich hoffe, sie hilft euch weiter.

Edit:
Nun zwei BSOD's direkt hintereinander

Ich denke, dass beste ist es, den Rechner neu aufzusetzen?
Was meint ihr?

Edit 2:
Meinen Rechner setze ich gerade neu auf.
Vielen Dank trotzdem an alle, die versucht haben mit mir das Problem zu lösen.
Vllt. findet man für andere ja noch heraus, an was es letztlich lag.

Frohe Ostern und viele Grüße
Astra-G

 

[simpel1970]

Aus dem Dumps konnte keine Ursache herausgefunden werden. Auch nicht mit laufendem Verifier.
Nun hoffe ich, dass dies kein Anzeichen dafür ist, dass die Probleme hardwareseitig auftreten.

Bin gespannt, ob die Neuinstallation hilft. Die Daumen sind gedrückt!

 

[Astra-G]

Kleine Rückmeldung: Der PC läuft wieder einwandfrei. War also kein Hardware-Defekt

 

[simpel1970]

Freut mich zu hören

@MagicAndre: das war jetzt so ein Fall, den du meintest (bei dem der Verifier nichts gebracht hatte).

 

[MagicAndre1981]

@MagicAndre: das war jetzt so ein Fall, den du meintest (bei dem der Verifier nichts gebracht hatte).

jupp, so war das bei mir auch immer.