Veel te vroeg gejuicht, random BSOD's zijn weer aan de orde van de dag... In verschillende games....
Ben met de windows debugger aan de slag gegaan zowel met de volledige DMP file als de mindumpfile, maar in beide gevallen zo ntkrnlmp.exe de schuldige moeten zijn. (of ik begrijp niet goed wat de debugger weergeeft, kan ook.)
Ik kan nergens vinden hoe ik nu verder moet. Uiteraard gegoogled, maar las niets wat het probleem kan oplossen. HEEEEELP!!!

Crash dmp info:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: D:\Mijn Storage\Debugger\Symbols 2
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a65000 PsLoadedModuleList = 0xfffff800`02ca2e50
Debug session time: Sat Dec 26 14:01:57.879 2009 (GMT+1)
System Uptime: 0 days 3:48:40.565
Loading Kernel Symbols
...............................................................
................................................................
...........................
Loading User Symbols
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck A, {0, 2, 0, fffff80002ae0ab1}
Probably caused by : ntkrnlmp.exe ( nt!KiTimerWaitTest+171 )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ae0ab1, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 0000000000000000
CURRENT_IRQL: 2
FAULTING_IP:
nt!KiTimerWaitTest+171
fffff800`02ae0ab1 488b6d00 mov rbp,qword ptr [rbp]
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TRAP_FRAME: fffff88002f8b3d0 -- (.trap 0xfffff88002f8b3d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=0000000000000000
rdx=fffffa80041695e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ae0ab1 rsp=fffff88002f8b560 rbp=0000000000000000
r8=fffff88002f65301 r9=0000000000000002 r10=000000000000009d
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz ac po cy
nt!KiTimerWaitTest+0x171:
fffff800`02ae0ab1 488b6d00 mov rbp,qword ptr [rbp] ss:0018:00000000`00000000=????????????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002ad6469 to fffff80002ad6f00
STACK_TEXT:
fffff880`02f8b288 fffff800`02ad6469 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`02f8b290 fffff800`02ad50e0 : fffff880`04b22897 fffffa80`041695e8 80000111`0000180e 00000000`00000002 : nt!KiBugCheckDispatch+0x69
fffff880`02f8b3d0 fffff800`02ae0ab1 : 00000000`00000000 00000000`0000000f 00000000`00000000 ffffe64a`1a3a7f9d : nt!KiPageFault+0x260
fffff880`02f8b560 fffff800`02ae22cd : fffffa80`041695e0 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiTimerWaitTest+0x171
fffff880`02f8b5e0 fffff800`02ae2e7e : 0000001f`f218289f fffff880`02f8bc58 00000000`000d6b9d fffff880`02f66928 : nt!KiProcessExpiredTimerList+0x6d
fffff880`02f8bc30 fffff800`02ae2697 : 0000000b`3b1234c1 0000000b`000d6b9d 0000000b`3b12347e 00000000`0000009d : nt!KiTimerExpiration+0x1be
fffff880`02f8bcd0 fffff800`02adf6fa : fffff880`02f63180 fffff880`02f6dfc0 00000000`00000000 fffff880`04ee7588 : nt!KiRetireDpcList+0x277
fffff880`02f8bd80 00000000`00000000 : fffff880`02f8c000 fffff880`02f86000 fffff880`02f8bd40 00000000`00000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiTimerWaitTest+171
fffff800`02ae0ab1 488b6d00 mov rbp,qword ptr [rbp]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!KiTimerWaitTest+171
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600
FAILURE_BUCKET_ID: X64_0xA_nt!KiTimerWaitTest+171
BUCKET_ID: X64_0xA_nt!KiTimerWaitTest+171
Followup: MachineOwner
---------