od momentu instalacji Windowsa 7 x64 na następującym sprzęcie:
Kod: Zaznacz cały
Procesor: AMD Phenom II 955
Płyta główna: ASUS M4A78LT-M
RAM: GoodRam GR1333D364L9 2x2GB
Dysk twardy: Samsung HD502HJwystępują u mnie częste blue screeny. Pojawiają się od momentu instalacji systemu. Czasami chwilę po włączeniu komputera, a innym razem po kilku godzinach. Wykonałem memtest osobno na każdej kości pamięci przez 1,5h. Nie było żadnych błędów.
Ciężko jest mi zauważyć podczas jakich konkretnie czynności pojawiają się błędy.
Oto kilka raportów:
Kod: Zaznacz cały
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\080811-13260-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 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17592.amd64fre.win7sp1_gdr.110408-1631
Machine Name:
Kernel base = 0xfffff800`02a61000 PsLoadedModuleList = 0xfffff800`02ca6650
Debug session time: Mon Aug 8 16:27:12.498 2011 (UTC + 2:00)
System Uptime: 0 days 1:09:38.199
Loading Kernel Symbols
...............................................................
................................................................
...............
Loading User Symbols
Loading unloaded module list
..............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck A, {2028, 2, 1, fffff80002afcfd9}
Probably caused by : ntkrnlmp.exe ( nt!KeReleaseSemaphore+329 )
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: 0000000000002028, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002afcfd9, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80002d10100
0000000000002028
CURRENT_IRQL: 2
FAULTING_IP:
nt!KeReleaseSemaphore+329
fffff800`02afcfd9 f083402801 lock add dword ptr [rax+28h],1
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TRAP_FRAME: fffff880031b6220 -- (.trap 0xfffff880031b6220)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000002000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002afcfd9 rsp=fffff880031b63b0 rbp=fffffa80055cd428
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff8a0082773d0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!KeReleaseSemaphore+0x329:
fffff800`02afcfd9 f083402801 lock add dword ptr [rax+28h],1 ds:6f00:00000000`00002028=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002ae02a9 to fffff80002ae0d00
STACK_TEXT:
fffff880`031b60d8 fffff800`02ae02a9 : 00000000`0000000a 00000000`00002028 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`031b60e0 fffff800`02adef20 : 00000000`0001c41f 00000000`000021b8 00000000`00001a02 fffffa80`055cd420 : nt!KiBugCheckDispatch+0x69
fffff880`031b6220 fffff800`02afcfd9 : 00000000`00000000 fffffa80`055cd060 fffffa80`055cd168 fffff800`02a282ec : nt!KiPageFault+0x260
fffff880`031b63b0 fffff800`02debef0 : fffffa80`00000000 fffff8a0`00000001 00000000`00000000 fffff8a0`08277200 : nt!KeReleaseSemaphore+0x329
fffff880`031b6430 fffff800`02ded6de : 00000000`00000000 fffff800`02ac5599 fffffa80`055d0031 fffff880`031b6558 : nt!AlpcpCompleteDispatchMessage+0xa10
fffff880`031b64c0 fffff800`02deafdf : fffff800`00010000 fffff8a0`06ef6958 fffff880`031b6920 00000002`fffffffe : nt!AlpcpDispatchNewMessage+0x24e
fffff880`031b6520 fffff800`02ded909 : fffff880`031b6900 00000000`00000001 00000000`00000000 00000000`00020000 : nt!AlpcpSendMessage+0x4ad
fffff880`031b6620 fffff800`02adff93 : fffffa80`036d6b60 fffff880`031b67c0 fffff880`031b68f8 00000000`00000080 : nt!NtAlpcSendWaitReceivePort+0xb9
fffff880`031b66d0 fffff800`02adc530 : fffff800`02aa35ae 00000000`00000000 00000000`0000000f 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`031b68d8 fffff800`02aa35ae : 00000000`00000000 00000000`0000000f 00000000`00000000 ffffdb3c`bb5c16cd : nt!KiServiceLinkage
fffff880`031b68e0 fffff800`02be47d8 : fffff8a0`079f4de0 00000000`00000000 fffff8a0`079f4de0 00000000`000007ff : nt!PopUmpoSendPowerMessage+0xae
fffff880`031b6b40 fffff800`02d47707 : fffff8a0`00b02e50 fffff8a0`01bb8cb0 fffff8a0`0254b860 fffff800`02d74021 : nt!PopUmpoSendPowerState+0x108
fffff880`031b6b90 fffff800`02d70b7f : fffff8a0`00b02e50 fffff8a0`01bb8cb0 fffff8a0`0254b860 fffff8a0`0254b850 : nt!PopCallPowerSettingCallback+0xa7
fffff880`031b6bc0 fffff800`02d70a03 : 00000000`00000000 fffff800`02dc4200 fffffa80`036d6b00 fffff800`00000000 : nt!PopDispatchPowerSettingCallbacks+0x14f
fffff880`031b6c10 fffff800`02a9e085 : 00000000`00000006 fffff800`02dc4481 00000000`00000000 00000000`00000000 : nt!PopPolicyWorkerNotify+0x47
fffff880`031b6c40 fffff800`02aeb021 : fffff800`00000003 fffffa80`00000008 fffff800`02a9df88 fffffa80`036d6b60 : nt!PopPolicyWorkerThread+0xfd
fffff880`031b6cb0 fffff800`02d7d32e : 00000000`00000000 fffffa80`036d6b60 00000000`00000080 fffffa80`0366b9e0 : nt!ExpWorkerThread+0x111
fffff880`031b6d40 fffff800`02ad2666 : fffff880`02f63180 fffffa80`036d6b60 fffff880`02f6dfc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`031b6d80 00000000`00000000 : fffff880`031b7000 fffff880`031b1000 fffff880`031b69e0 00000000`00000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeReleaseSemaphore+329
fffff800`02afcfd9 f083402801 lock add dword ptr [rax+28h],1
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!KeReleaseSemaphore+329
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9fdd5b
FAILURE_BUCKET_ID: X64_0xA_nt!KeReleaseSemaphore+329
BUCKET_ID: X64_0xA_nt!KeReleaseSemaphore+329
Followup: MachineOwner
---------
Kod: Zaznacz cały
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\080511-14118-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 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17592.amd64fre.win7sp1_gdr.110408-1631
Machine Name:
Kernel base = 0xfffff800`02a17000 PsLoadedModuleList = 0xfffff800`02c5c650
Debug session time: Fri Aug 5 11:16:31.220 2011 (UTC + 2:00)
System Uptime: 0 days 0:04:16.921
Loading Kernel Symbols
.
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
..............................................................
................................................................
.................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck C2, {7, 109b, 57bab30, fffffa80059d66e0}
GetPointerFromAddress: unable to read from fffff80002cc6100
Probably caused by : ntkrnlmp.exe ( nt!IopCreateFile+80c )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 000000000000109b, (reserved)
Arg3: 00000000057bab30, Memory contents of the pool block
Arg4: fffffa80059d66e0, Address of the block of pool being deallocated
Debugging Details:
------------------
POOL_ADDRESS: fffffa80059d66e0
FREED_POOL_TAG: EtwR
BUGCHECK_STR: 0xc2_7_EtwR
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: svchost.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80002bc1be9 to fffff80002a96d00
STACK_TEXT:
fffff880`07c259c8 fffff800`02bc1be9 : 00000000`000000c2 00000000`00000007 00000000`0000109b 00000000`057bab30 : nt!KeBugCheckEx
fffff880`07c259d0 fffff800`02d93f40 : 00000000`00000001 00000000`00000001 00000000`00000000 00000000`00000000 : nt!ExDeferredFreePool+0x1201
fffff880`07c25a80 fffff800`02d9e608 : 00000000`0141eac8 fffff8a0`80100080 00000000`0141eb18 00000000`0141ead8 : nt!IopCreateFile+0x80c
fffff880`07c25b20 fffff800`02a95f93 : fffffa80`05646060 00000000`00000001 fffffa80`056a7970 fffff800`02d8dbc4 : nt!NtCreateFile+0x78
fffff880`07c25bb0 00000000`7732186a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0141ea48 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7732186a
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!IopCreateFile+80c
fffff800`02d93f40 e983fbffff jmp nt!IopCreateFile+0x398 (fffff800`02d93ac8)
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!IopCreateFile+80c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9fdd5b
FAILURE_BUCKET_ID: X64_0xc2_7_EtwR_nt!IopCreateFile+80c
BUCKET_ID: X64_0xc2_7_EtwR_nt!IopCreateFile+80c
Followup: MachineOwner
---------
Kod: Zaznacz cały
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\080511-12745-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 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17592.amd64fre.win7sp1_gdr.110408-1631
Machine Name:
Kernel base = 0xfffff800`02a63000 PsLoadedModuleList = 0xfffff800`02ca8650
Debug session time: Fri Aug 5 11:23:30.619 2011 (UTC + 2:00)
System Uptime: 0 days 0:06:23.931
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, fffff80002aa4309}
Probably caused by : ntkrnlmp.exe ( nt!KiActivateWaiterQueue+69 )
Followup: MachineOwner
---------
1: 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: fffff80002aa4309, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002d12100
0000000000000000
CURRENT_IRQL: 2
FAULTING_IP:
nt!KiActivateWaiterQueue+69
fffff800`02aa4309 488b0f mov rcx,qword ptr [rdi]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: lsm.exe
TRAP_FRAME: fffff88007ee87b0 -- (.trap 0xfffff88007ee87b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000032e6140 rbx=0000000000000000 rcx=fffffa80054d3950
rdx=fffffa80054d1980 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002aa4309 rsp=fffff88007ee8940 rbp=fffffa80054d3958
r8=0000000000000000 r9=0000000000000000 r10=fffffffffffffffd
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz ac pe cy
nt!KiActivateWaiterQueue+0x69:
fffff800`02aa4309 488b0f mov rcx,qword ptr [rdi] ds:00000000`00000000=????????????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002ae22a9 to fffff80002ae2d00
STACK_TEXT:
fffff880`07ee8668 fffff800`02ae22a9 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`07ee8670 fffff800`02ae0f20 : 00000000`00000008 fffff800`02ae58a4 fffffa80`00000001 fffffa80`054d3950 : nt!KiBugCheckDispatch+0x69
fffff880`07ee87b0 fffff800`02aa4309 : fffffa80`059852a0 fffffa80`059852a0 00000000`00000000 00000000`00000001 : nt!KiPageFault+0x260
fffff880`07ee8940 fffff800`02aa4447 : fffffa80`054d3950 fffffa80`059852a0 fffff800`02d162c0 fffff880`07ee8be0 : nt!KiActivateWaiterQueue+0x69
fffff880`07ee8980 fffff800`02b5b33b : 00000001`0cc69d49 00000000`00000000 fffffa80`059852a0 fffffa80`054d1950 : nt!KiSlowActivateWaiterQueue+0xf3
fffff880`07ee89d0 fffff800`02dcad07 : fffff800`02c68900 00000000`00000001 fffff8a0`03734801 000007fe`ff890000 : nt! ?? ::FNODOBFM::`string'+0x4c61b
fffff880`07ee8a90 fffff800`02acebb6 : 000007fe`00000000 fffff880`07ee8ba8 fffff880`07ee8bc8 00000000`00000001 : nt!IoRemoveIoCompletion+0x47
fffff880`07ee8b20 fffff800`02ae1f93 : fffffa80`059852a0 00000000`77bb45c0 00000000`00000102 00000000`80070000 : nt!NtWaitForWorkViaWorkerFactory+0x285
fffff880`07ee8c20 00000000`77b02c1a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`00e7f688 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77b02c1a
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiActivateWaiterQueue+69
fffff800`02aa4309 488b0f mov rcx,qword ptr [rdi]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!KiActivateWaiterQueue+69
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9fdd5b
FAILURE_BUCKET_ID: X64_0xA_nt!KiActivateWaiterQueue+69
BUCKET_ID: X64_0xA_nt!KiActivateWaiterQueue+69
Followup: MachineOwner
---------
1: 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: fffff80002aa4309, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 0000000000000000
CURRENT_IRQL: 2
FAULTING_IP:
nt!KiActivateWaiterQueue+69
fffff800`02aa4309 488b0f mov rcx,qword ptr [rdi]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: lsm.exe
TRAP_FRAME: fffff88007ee87b0 -- (.trap 0xfffff88007ee87b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000032e6140 rbx=0000000000000000 rcx=fffffa80054d3950
rdx=fffffa80054d1980 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002aa4309 rsp=fffff88007ee8940 rbp=fffffa80054d3958
r8=0000000000000000 r9=0000000000000000 r10=fffffffffffffffd
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz ac pe cy
nt!KiActivateWaiterQueue+0x69:
fffff800`02aa4309 488b0f mov rcx,qword ptr [rdi] ds:00000000`00000000=????????????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002ae22a9 to fffff80002ae2d00
STACK_TEXT:
fffff880`07ee8668 fffff800`02ae22a9 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`07ee8670 fffff800`02ae0f20 : 00000000`00000008 fffff800`02ae58a4 fffffa80`00000001 fffffa80`054d3950 : nt!KiBugCheckDispatch+0x69
fffff880`07ee87b0 fffff800`02aa4309 : fffffa80`059852a0 fffffa80`059852a0 00000000`00000000 00000000`00000001 : nt!KiPageFault+0x260
fffff880`07ee8940 fffff800`02aa4447 : fffffa80`054d3950 fffffa80`059852a0 fffff800`02d162c0 fffff880`07ee8be0 : nt!KiActivateWaiterQueue+0x69
fffff880`07ee8980 fffff800`02b5b33b : 00000001`0cc69d49 00000000`00000000 fffffa80`059852a0 fffffa80`054d1950 : nt!KiSlowActivateWaiterQueue+0xf3
fffff880`07ee89d0 fffff800`02dcad07 : fffff800`02c68900 00000000`00000001 fffff8a0`03734801 000007fe`ff890000 : nt! ?? ::FNODOBFM::`string'+0x4c61b
fffff880`07ee8a90 fffff800`02acebb6 : 000007fe`00000000 fffff880`07ee8ba8 fffff880`07ee8bc8 00000000`00000001 : nt!IoRemoveIoCompletion+0x47
fffff880`07ee8b20 fffff800`02ae1f93 : fffffa80`059852a0 00000000`77bb45c0 00000000`00000102 00000000`80070000 : nt!NtWaitForWorkViaWorkerFactory+0x285
fffff880`07ee8c20 00000000`77b02c1a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`00e7f688 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77b02c1a
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiActivateWaiterQueue+69
fffff800`02aa4309 488b0f mov rcx,qword ptr [rdi]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!KiActivateWaiterQueue+69
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9fdd5b
FAILURE_BUCKET_ID: X64_0xA_nt!KiActivateWaiterQueue+69
BUCKET_ID: X64_0xA_nt!KiActivateWaiterQueue+69
Followup: MachineOwner
---------
Kod: Zaznacz cały
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\080311-13213-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 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17592.amd64fre.win7sp1_gdr.110408-1631
Machine Name:
Kernel base = 0xfffff800`02a09000 PsLoadedModuleList = 0xfffff800`02c4e650
Debug session time: Wed Aug 3 13:37:17.554 2011 (UTC + 2:00)
System Uptime: 0 days 0:02:13.255
Loading Kernel Symbols
...............................................................
................................................................
.
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck C2, {7, 109b, 56eb000, fffffa80056e3010}
GetPointerFromAddress: unable to read from fffff80002cb8100
GetUlongFromAddress: unable to read from fffff80002c26a18
Probably caused by : fileinfo.sys ( fileinfo!FIStreamGetInfo+11f )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 000000000000109b, (reserved)
Arg3: 00000000056eb000, Memory contents of the pool block
Arg4: fffffa80056e3010, Address of the block of pool being deallocated
Debugging Details:
------------------
GetUlongFromAddress: unable to read from fffff80002c26a18
POOL_ADDRESS: fffffa80056e3010
BUGCHECK_STR: 0xc2_7
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: svchost.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80002bb3be9 to fffff80002a88d00
STACK_TEXT:
fffff880`02735ee8 fffff800`02bb3be9 : 00000000`000000c2 00000000`00000007 00000000`0000109b 00000000`056eb000 : nt!KeBugCheckEx
fffff880`02735ef0 fffff800`02d85f40 : 00000000`00000000 00000000`00000001 00000000`00000000 fffff880`02735fb8 : nt!ExDeferredFreePool+0x1201
fffff880`02735fa0 fffff800`02d2ec2b : fffffa80`04beda08 fffffa80`00100001 fffff880`02736190 fffff880`02736160 : nt!IopCreateFile+0x80c
fffff880`02736040 fffff880`00c24180 : fffffa80`04bed930 00000000`00000017 fffffa80`04bb5568 00000000`00000000 : nt!IoCreateFileEx+0xfb
fffff880`027360e0 fffff880`00c23be9 : fffffa80`04bb5568 00000000`00000000 00000000`00000017 fffff880`00c24fe0 : fltmgr!FltpNormalizeNameFromCache+0x190
fffff880`02736200 fffff880`00c24f81 : fffffa80`00000072 00000000`00000072 00000000`00000035 00000000`00000000 : fltmgr!FltpExpandShortNames+0x239
fffff880`02736260 fffff880`00c24e1e : fffffa80`04bed930 fffff880`00c20000 00000000`00000000 00000000`00000000 : fltmgr!FltpGetNormalizedFileNameWorker+0xc1
fffff880`027362a0 fffff880`00c064fb : fffffa80`03786080 00000000`00000000 fffffa80`055cad80 fffff880`02737000 : fltmgr!FltpCreateFileNameInformation+0xee
fffff880`02736300 fffff880`00c11b44 : 00000000`00008000 fffffa80`055cad80 00000000`00000000 00000000`00000401 : fltmgr!FltpGetFileNameInformation+0x26b
fffff880`02736380 fffff880`010fd36b : fffffa80`04bed930 fffff8a0`02aaea10 00000000`00000001 fffff880`027364b0 : fltmgr!FltGetFileNameInformation+0x184
fffff880`02736410 fffff880`010fbbdb : fffff140`02c32507 00000000`00000001 00000000`00000000 00000000`00000383 : fileinfo!FIStreamGetInfo+0x11f
fffff880`02736490 fffff880`00c04288 : 00000000`00000000 fffff8a0`02aaea10 fffffa80`057713b0 00000000`00000000 : fileinfo!FIPostCreateCallback+0x1c7
fffff880`02736520 fffff880`00c02d1b : fffffa80`046b9030 fffffa80`056cfa00 fffffa80`04bb0010 fffffa80`04bb0230 : fltmgr!FltpPerformPostCallbacks+0x368
fffff880`027365f0 fffff880`00c222b9 : fffffa80`05771010 fffffa80`04761010 fffffa80`05771000 fffffa80`04689de0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x39b
fffff880`02736680 fffff800`02d86625 : 00000000`00000005 fffffa80`0554fcc8 fffffa80`05520b10 00000000`00000000 : fltmgr!FltpCreate+0x2a9
fffff880`02736730 fffff800`02d82ec8 : fffffa80`045eebd0 fffff800`00000000 fffffa80`0554fb10 fffff8a0`00000001 : nt!IopParseDevice+0x5a5
fffff880`027368c0 fffff800`02d840e6 : 00000000`00000000 fffffa80`0554fb10 00000000`00000000 fffffa80`036e2660 : nt!ObpLookupObjectName+0x588
fffff880`027369b0 fffff800`02d859ec : fffffa80`055ccec8 00000000`00000000 fffff8a0`02bb0501 fffff8a0`02b04c50 : nt!ObOpenObjectByName+0x306
fffff880`02736a80 fffff800`02d90608 : 00000000`0138dbc8 00000000`c0100080 00000000`0138dc18 00000000`0138dbd8 : nt!IopCreateFile+0x2bc
fffff880`02736b20 fffff800`02a87f93 : fffffa80`055d9360 fffff880`02736ca0 00000000`00000000 00000980`00000000 : nt!NtCreateFile+0x78
fffff880`02736bb0 00000000`7724186a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0138db48 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7724186a
STACK_COMMAND: kb
FOLLOWUP_IP:
fileinfo!FIStreamGetInfo+11f
fffff880`010fd36b 85c0 test eax,eax
SYMBOL_STACK_INDEX: a
SYMBOL_NAME: fileinfo!FIStreamGetInfo+11f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: fileinfo
IMAGE_NAME: fileinfo.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc481
FAILURE_BUCKET_ID: X64_0xc2_7_fileinfo!FIStreamGetInfo+11f
BUCKET_ID: X64_0xc2_7_fileinfo!FIStreamGetInfo+11f
Followup: MachineOwner
---------Ponadto sprzęt wcześniej należał do mojego brata (z wyłączeniem dysku twardego, który zastąpiłem nowym) i u niego na 32-bitowym Windowsie 7 nie było żadnych problemów.
Proszę o pomoc i z góry dziękuję.
