Problem, jednak nie znikł. Nadal mam BSoDy, jedynie częstotliwość ich występowania się zmniejszyła. Przetestowałem pamięci memtest86+ przez jakieś 8-9 godzin i żadnego błędu. Nie wiem, co może być przyczyną. Problemy pojawiły się po zainstalowaniu Win7 z starszej bootowalnej płytki, czy przyczyną może być wadliwa instalacja Win7, lub wadliwa płytka?
Loading Dump File [C:\Users\Damian\Desktop\012911-16582-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 (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`02c1f000 PsLoadedModuleList = 0xfffff800`02e5ce50
Debug session time: Sat Jan 29 23:15:35.715 2011 (UTC + 1:00)
System Uptime: 0 days 2:37:19.400
Loading Kernel Symbols
...............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {28, 2, 0, fffff88001473c1e}
Unable to load image \SystemRoot\system32\DRIVERS\L1E62x64.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for L1E62x64.sys
*** ERROR: Module load completed but symbols could not be loaded for L1E62x64.sys
Probably caused by : L1E62x64.sys ( L1E62x64+76b8 )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000028, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff88001473c1e, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002ec70e0
0000000000000028
CURRENT_IRQL: 2
FAULTING_IP:
ndis! ?? ::FNODOBFM::`string'+14dd
fffff880`01473c1e 8b4728 mov eax,dword ptr [rdi+28h]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: fffff880037b0280 -- (.trap 0xfffff880037b0280)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000026
rdx=fffffa8004283a70 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001473c1e rsp=fffff880037b0410 rbp=fffffa8005290b30
r8=fffffa8005aa40c0 r9=0000000000000001 r10=0000000000000000
r11=fffffa80051051a0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
ndis! ?? ::FNODOBFM::`string'+0x14dd:
fffff880`01473c1e 8b4728 mov eax,dword ptr [rdi+28h] ds:2a80:00000000`00000028=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002c8eca9 to fffff80002c8f740
STACK_TEXT:
fffff880`037b0138 fffff800`02c8eca9 : 00000000`0000000a 00000000`00000028 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`037b0140 fffff800`02c8d920 : 00000000`00000000 fffffa80`04283a70 fffffa80`05aa4060 fffffa80`05499000 : nt!KiBugCheckDispatch+0x69
fffff880`037b0280 fffff880`01473c1e : fffffa80`03fcfae0 fffffa80`05290b30 fffff880`000000a0 00000000`00000000 : nt!KiPageFault+0x260
fffff880`037b0410 fffff880`069eb6b8 : fffffa80`051051a0 00000000`00000000 fffffa80`05aa40c0 fffffa80`05290b30 : ndis! ?? ::FNODOBFM::`string'+0x14dd
fffff880`037b04b0 fffffa80`051051a0 : 00000000`00000000 fffffa80`05aa40c0 fffffa80`05290b30 fffffa80`05aaa380 : L1E62x64+0x76b8
fffff880`037b04b8 00000000`00000000 : fffffa80`05aa40c0 fffffa80`05290b30 fffffa80`05aaa380 00000000`000001c0 : 0xfffffa80`051051a0
STACK_COMMAND: kb
FOLLOWUP_IP:
L1E62x64+76b8
fffff880`069eb6b8 ?? ???
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: L1E62x64+76b8
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: L1E62x64
IMAGE_NAME: L1E62x64.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a90ceb9
FAILURE_BUCKET_ID: X64_0xD1_L1E62x64+76b8
BUCKET_ID: X64_0xD1_L1E62x64+76b8
Followup: MachineOwner
---------