Computer schmiert beim zocken ab

Ich hoffe das war jetzt nicht einfach nur Glück oder Zufall aber ich hatte keinen Absturz :D
Hab einen RAM Riegel rausgenommen, sodass der Slot der die letzte Zeit nicht belegt war wieder frei ist und nach erstem Spielen gabs erstmal keine Probleme
Werd jetzt so lang zocken bis er wieder abstürzt und wenn er nicht abstürzt freu ich mich einfach und bestell mir einen 4 GB Riegel^^
Sollte er abstürzen nehm ich mir das BIOS vor
 
Hast Du den RAM Slot, der lange unbenutzt war, mal gründlich ausgeblasen und entstaubt? Könnte auch daran liegen.
 
Probier mal, die Minidump vom Bluescreen auszulesen, das könnt auch noch weiterhelfen.

Dauert vielleicht 10 Minuten, dann kannst du das Protokoll auslesen und z.B. hier posten

Bei den Bluescreens wurde eine Minidump geschrieben (C:\Windows\Minidump\Mini022410-01.dmp).
Diese kann ausgewertet werden. Wenn der Bluescreen von einem Treiber verursacht wurde, könnte die evtl. hilfreich sein, um dem (fehlerhaften) Treiber auf die Schliche zu kommen.

Um die Minidump auszuwerten, brauchst du das Debugging Tool for Windows -Link zur 64-bit Version-. Falls du Win7/Vista 32-bit draufhast diese Version.

Nach der Installation findest du im Programmverzeichnis die 'Debugging Tools for Windows'. Hier befindet sich die Datei windbg.exe, diese starten (bei Win7/Vista als Administrator starten).
Der Debugger muss zunächst noch verschiedene Informationen über installierte Patches, SPs, Treiber, etc., bekommen. Dies macht er eigenständig...einfach warten.
Dann auf Files -> Symbol File Path und in das kleine Fenster folgenden Befehl eingeben (paste&copy):

"SRV*C:\symbols*http://msdl.microsoft.com/download/symbols" (ohne "")

einen Haken bei 'Reload' (sofern es nicht ausgegraut ist) und OK drücken. Jetzt können alle notwendigen Informationen zum Debuggen von MS geladen werden, das geschieht automatisch.
Anschließend über Files, das Speicherabbild für den Debugger öffnen: Files -> Open Crash Dump
Memory.dmp auswählen und öffnen (Speicherpfad der dmp Datei ist C:\Windows bzw. C:\Windows\Minidump).
Im letzten Schritt in die untere Befehlszeile "!analyze –v" eingeben und Entertaste drücken.

Der Debugger werkelt dann etwas und nach kurzer wird als Ausgabe eine Zuweisung der Datei, die den Bluescreens hervorgerufen hat, gegeben.

Den Text der Auswertung kannst du dann uns posten.

An dieser Stelle noch mal danke an simpel1970 für die Anleitung und die Links :daumen:

Link zum Originalbeitrag :

http://extreme.pcgameshardware.de/k...-bluescreen-wie-jetzt-weiter.html#post1595813

Wenn du, so wie ich, Probleme mit Adminrechten bekommen solltest, hilft dir das vielleicht noch weiter :

http://www.noobtech.at/938/administrator-unter-windows-7-freischalten/
 
Zuletzt bearbeitet:
Hast Du den RAM Slot, der lange unbenutzt war, mal gründlich ausgeblasen und entstaubt? Könnte auch daran liegen.

Jap das hab ich schon gemacht^^

@CoSinus
Ich kann das irgendwie nicht installieren, die Installation wird nach ungefähr einer Minute abgebrochen mit einem Verweis auf eine Logdatei mit genaueren Infos, die ich hab nirgendwo finde
Es bringt nichts wenn ich euch die Minidumps hochlade oder?
 
Als ich das installiert hab, kam ne Seite mit verschiedenen Programmen und Optionen zum Anhaken.
Versuch mal alle Programme die dort möglich sind abzuwählen ,mit Ausnahme des Debugging Tools.

Hab das Tool gestern erst auf nem LapTop installiert, da kam (soweit ich mich erinnern kann) keine Fehlermeldung

Wenns sich nicht installieren lassen will, kannst du ja trotzdem noch die MiniDumps hochladen
 
funktioniert auch nicht :ugly:
und irgendwie kann ich die minidumps auch nicht hochladen, auf uploaded.to etc funktionierts nicht und sie in eine *.zip packen um sie hier hochzuladen funktioniert ebenso wenig :huh:
 
Kannst sie ja an mich schicken, Email müsste in meinem Profil zu finden sein.
Ich übersetz sie dann und stell sie rein =)
 
So ,hier die Dump:

Alles in Rot find ich nen Blick wert

012012-33150-01.dmp

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


Loading Dump File [F:\012012-33150-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c66000 PsLoadedModuleList = 0xfffff800`02ea3e50
Debug session time: Thu Jan 19 14:31:18.782 2012 (UTC - 8:00)
System Uptime: 0 days 0:21:53.093
Loading Kernel Symbols
...............................................................
................................................................
.......................
Loading User Symbols
Loading unloaded module list
......
Unable to load image \SystemRoot\system32\DRIVERS\atikmdag.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for atikmdag.sys
*** ERROR: Module load completed but symbols could not be loaded for atikmdag.sys
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007E, {ffffffffc0000096, fffff88004b01153, fffff88001f3c9e8, fffff88001f3c240}

Probably caused by : atikmdag.sys ( atikmdag+4c4153 )

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

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

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffffc0000096, The exception code that was not handled
Arg2: fffff88004b01153, The address that the exception occurred at
Arg3: fffff88001f3c9e8, Exception Record Address
Arg4: fffff88001f3c240, Context Record Address

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000096 - {AUSNAHME} Privilegierte Anweisung

FAULTING_IP:
atikmdag+4c4153
fffff880`04b01153 0f ???

EXCEPTION_RECORD: fffff88001f3c9e8 -- (.exr 0xfffff88001f3c9e8)
ExceptionAddress: fffff88004b01153 (atikmdag+0x00000000004c4153)
ExceptionCode: c0000096
ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT: fffff88001f3c240 -- (.cxr 0xfffff88001f3c240)
rax=8604a796b18a76b1 rbx=8604a796b18a76b1 rcx=0000000000000018
rdx=8604a796b18a76b1 rsi=fffff88004d6fe60 rdi=0000000000000000
rip=fffff88004b01153 rsp=fffff88001f3cc28 rbp=fffff88001f3cd30
r8=fffff88004b01153 r9=fffff88001f3cc78 r10=000003953ce173c1
r11=00000000000002f1 r12=0000000000000400 r13=0000000000000020
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl nz ac pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010012
atikmdag+0x4c4153:
fffff880`04b01153 0f ???
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000096 - {AUSNAHME} Privilegierte Anweisung

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: STATUS_PRIVILEGED_INSTRUCTION

LAST_CONTROL_TRANSFER: from fffff88004ac7338 to fffff88004b01153

STACK_TEXT:
fffff880`01f3cc28 fffff880`04ac7338 : 00000000`00000004 00000000`00000000 00000000`00007900 fffff880`04d6fe00 : atikmdag+0x4c4153
fffff880`01f3cc30 00000000`00000004 : 00000000`00000000 00000000`00007900 fffff880`04d6fe00 fffff800`02e50e80 : atikmdag+0x48a338
fffff880`01f3cc38 00000000`00000000 : 00000000`00007900 fffff880`04d6fe00 fffff800`02e50e80 00000000`0081dc35 : 0x4


FOLLOWUP_IP:
atikmdag+4c4153
fffff880`04b01153 0f ???

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: atikmdag+4c4153

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: atikmdag

IMAGE_NAME: atikmdag.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ebb3c7e

STACK_COMMAND: .cxr 0xfffff88001f3c240 ; kb

FAILURE_BUCKET_ID: X64_0x7E_atikmdag+4c4153

BUCKET_ID: X64_0x7E_atikmdag+4c4153

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


011512-17877-01.dmp


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


Loading Dump File [F:\011512-17877-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c0a000 PsLoadedModuleList = 0xfffff800`02e47e50
Debug session time: Sun Jan 15 14:38:43.115 2012 (UTC - 8:00)
System Uptime: 0 days 0:32:40.427
Loading Kernel Symbols
...............................................................
................................................................
......................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 4E, {99, 60652, 0, 50552}

Probably caused by : memory_corruption ( nt!MiBadShareCount+4c )

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

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

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc). If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 0000000000000099, A PTE or PFN is corrupt
Arg2: 0000000000060652, page frame number
Arg3: 0000000000000000, current page state
Arg4: 0000000000050552, 0

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


BUGCHECK_STR: 0x4E_99

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: firefox.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80002d0a32c to fffff80002c7bf00

STACK_TEXT:
fffff880`084800f8 fffff800`02d0a32c : 00000000`0000004e 00000000`00000099 00000000`00060652 00000000`00000000 : nt!KeBugCheckEx
fffff880`08480100 fffff800`02c3154e : 00000000`00000000 fffff680`0002e910 00000000`00000002 00000000`00000001 : nt!MiBadShareCount+0x4c
fffff880`08480140 fffff800`02c50493 : fffffa80`03e2c060 fffff700`0000381a 0000007f`fffffff8 fffff8a0`00d883d8 : nt! ?? ::FNODOBFM::`string'+0x322b5
fffff880`084801d0 fffff800`02c4eeee : fffffa80`03e2c060 fffffa80`00000067 fffff8a0`00000c9b 00000000`00000000 : nt!MiDeleteAddressesInWorkingSet+0x307
fffff880`08480a80 fffff800`02f5e7af : fffff8a0`0dcc6590 00000000`00000001 00000000`00000000 fffffa80`0453d060 : nt!MmCleanProcessAddressSpace+0x96
fffff880`08480ad0 fffff800`02f37cb8 : 00000000`00000000 00000000`00000001 00000000`fffdb000 00000000`00000000 : nt!PspExitThread+0x47f
fffff880`08480ba0 fffff800`02c7b153 : fffffa80`03e2c060 00000000`00000000 fffffa80`0453d060 fffffa80`06462be0 : nt!NtTerminateProcess+0x138
fffff880`08480c20 00000000`778e017a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0013e2d8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x778e017a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiBadShareCount+4c
fffff800`02d0a32c cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!MiBadShareCount+4c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0x4E_99_nt!MiBadShareCount+4c

BUCKET_ID: X64_0x4E_99_nt!MiBadShareCount+4c

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

010312-15444-01.dmp


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


Loading Dump File [F:\010312-15444-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (3 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c08000 PsLoadedModuleList = 0xfffff800`02e45e50
Debug session time: Mon Jan 2 18:46:42.802 2012 (UTC - 8:00)
System Uptime: 0 days 14:39:38.333
Loading Kernel Symbols
...............................................................
................................................................
....................
Loading User Symbols
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a039d896892554, 0, f5bca5bf8ce3ada9, 101}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

2: 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 Patching Policy for x64-Based Systems
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: a3a039d896892554, Reserved
Arg2: 0000000000000000, Reserved
Arg3: f5bca5bf8ce3ada9, Failure type dependent information
Arg4: 0000000000000101, 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:
------------------


BUGCHECK_STR: 0x109

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80002c79f00

STACK_TEXT:
fffff880`0314e5d8 00000000`00000000 : 00000000`00000109 a3a039d8`96892554 00000000`00000000 f5bca5bf`8ce3ada9 : 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

BUCKET_ID: BAD_STACK

Followup: MachineOwner
---------
 
Zuletzt bearbeitet:
Sieh mal im Taskmanager nach, welches Programm unter der ersten rot markierten Bezeichnung ausgeführt wird.
Morgen seh ich mir das nach der Arbeit mal genauer an
 
Zuletzt bearbeitet:
Ich würde ein BIOS Update machen, das könnte in dem Fall helfen.

Die BSOD's könnten auch durch einen Speicherfehler zustande kommen, da kommt neben dem RAM aber auch der VRAM der Grafikkarte, die HDD oder die CPU in Frage. :(
 
CPU ist eher auszuschließen, die wurde erst vor kurzem gewechselt und bei der vorherigen gab es die selben Fehler.
 
@CoSinus
Im Taskmanager steht kein Programm und auch kein Prozess mit dem Namen oder der Bezeichnung von dem ersten rot markiertem

@Softy
Den RAM würd ich mittlerweile eigentlich gänzlich ausschließen als Fehlerquelle, CPU siehe Ibatz! und HDD oder Grafikkarte wär natürlich noch eine Möglichkeit, hoffe ich allerdings nicht weil beides momentan schweineteuer ist :ugly:

Allerdings ist auch das Mainboard wieder voll im Rennen. Habe heute Mittag wie glaube ich schon erwähnt den RAM Riegel aus dem vermeintlich defekten Slot genommen und seitdem läuft der Rechner durch ohne einen Absturz und das mit zwischenzeitlichem BF3 Zocken
 
Dann würde ich ein BIOS Update machen, und eine andere Grafikkarte testen. Wenn der Fehler dann immer noch auftritt, würde ich das Board austauschen.
 
Das Problem tritt dann nur auf, wenn der eine Slot mit einem Riegel belegt wird?
Der RAM insbesamt läuft ansonsten fehlerfrei (jeder Riegel / in den anderen Slots)?
 
@simpel1970 exakt das
@rigg83 coretemp hat mir bislang nicht höheres als 49°C gesagt (nach Beenden von BF3, beim surfen sinds um die 25°C)
 
Zurück