Nawiązując do tej wypowiedzi. Problemem są BSOD / restarty komputera w kółko. Zaczęły się od wyjęcia i włożenia tej samej grafiki PCI-E, ale nie od razu. Trochę pokombinowałem i odkryłem taką zasadę:
1. System ładuje się dobrze z PCI-E.
2. System automatycznie instaluje sterowniki do mostka PCI i do tego co przy okazji znajdzie.
3. Uruchamiam ponownie komputer i w trakcie ładowania OS klapa.
Wracam funkcją Restore do czasu sprzed automatycznego instalowania sterowników.
Po pkcie drugim odinstalowuje w menadżerze urządzeń dopiero co zainstalowany mostek PCI.
Wtedy po restarcie komputer normalnie działa, ale znowu uparcie instaluje sterowniki z automatu, więc jeśli chcę jakkolwiek pracować, muszę je odinstalowywać:D.
Z jakiegoś powodu w menadżerze mam tych mostków Dostępne tylko dla zarejestrowanych użytkowników.
Szczegóły minidump'a (WinDbg x86 na Win7 x64):
Kod: Zaznacz cały
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\admin\Desktop\120411-21574-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
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0280c000 PsLoadedModuleList = 0xfffff800`02a51670
Debug session time: Sun Dec 4 03:57:21.215 2011 (GMT+1)
System Uptime: 0 days 0:00:12.792
Loading Kernel Symbols
...............................................................
..................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80050031, 6f8, fffff8000288b572}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff8000288b572
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff800028881e9 to fffff80002888c40
STACK_TEXT:
fffff880`02fd9ce8 fffff800`028881e9 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`02fd9cf0 fffff800`028866b2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`02fd9e30 fffff800`0288b572 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff800`009b0fb0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchInterrupt+0x32
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b2
fffff800`028866b2 90 nop
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiDoubleFaultAbort+b2
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3
FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b2
BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b2
Followup: MachineOwner
---------
Pzdr!
-- 04 gru 2011, 14:45 --
A tutaj dwa kolejne minidumpy, ale tym razem jeden w trakcie pracy (zaraz po napisaniu posta) a nie podczas ładowania systemu, a drugi wyskoczył w późniejszym procesie ładowania systemu niż zwykle.
Kod: Zaznacz cały
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\admin\Desktop\120411-21574-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
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0280c000 PsLoadedModuleList = 0xfffff800`02a51670
Debug session time: Sun Dec 4 03:57:21.215 2011 (GMT+1)
System Uptime: 0 days 0:00:12.792
Loading Kernel Symbols
...............................................................
..................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80050031, 6f8, fffff8000288b572}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff8000288b572
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff800028881e9 to fffff80002888c40
STACK_TEXT:
fffff880`02fd9ce8 fffff800`028881e9 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`02fd9cf0 fffff800`028866b2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`02fd9e30 fffff800`0288b572 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff800`009b0fb0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchInterrupt+0x32
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b2
fffff800`028866b2 90 nop
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiDoubleFaultAbort+b2
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3
FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b2
BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b2
Followup: MachineOwner
---------
Kod: Zaznacz cały
Loading Dump File [C:\Users\admin\Desktop\120411-35069-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
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02a4b000 PsLoadedModuleList = 0xfffff800`02c90670
Debug session time: Sun Dec 4 13:36:01.426 2011 (GMT+1)
System Uptime: 0 days 0:00:47.002
Loading Kernel Symbols
...............................................................
................................................................
..................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck FC, {fffff8a0074262b0, fb900000765a2963, fffff8800318c7b0, 2}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+45d8c )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory. The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff8a0074262b0, Virtual address for the attempted execute.
Arg2: fb900000765a2963, PTE contents.
Arg3: fffff8800318c7b0, (reserved)
Arg4: 0000000000000002, (reserved)
Debugging Details:
------------------
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xFC
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffff8800318c7b0 -- (.trap 0xfffff8800318c7b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000ffffffff rbx=0000000000000000 rcx=fffff8a007426178
rdx=fffffa8003a05b60 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8a0074262b0 rsp=fffff8800318c948 rbp=0000000000000130
r8=ffffffffffffffff r9=ffffffffffffffff r10=fffff80002a4b000
r11=fffff8a0077c7710 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
fffff8a0`074262b0 b062 mov al,62h
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002a736c4 to fffff80002ac7c40
STACK_TEXT:
fffff880`0318c648 fffff800`02a736c4 : 00000000`000000fc fffff8a0`074262b0 fb900000`765a2963 fffff880`0318c7b0 : nt!KeBugCheckEx
fffff880`0318c650 fffff800`02ac5d6e : 00000000`00000008 fffff8a0`074262b0 00000000`00000000 00000000`00000001 : nt! ?? ::FNODOBFM::`string'+0x45d8c
fffff880`0318c7b0 fffff8a0`074262b0 : fffff800`02d8090e 00000000`00000001 fffff880`012dc0d8 fffff880`0318c9f0 : nt!KiPageFault+0x16e
fffff880`0318c948 fffff800`02d8090e : 00000000`00000001 fffff880`012dc0d8 fffff880`0318c9f0 00000000`00000000 : 0xfffff8a0`074262b0
fffff880`0318c950 fffff880`012dbbac : fffff8a0`07432930 fffffa80`03a05b60 fffff880`0318ca28 00000000`00000706 : nt!FsRtlTeardownPerStreamContexts+0xe2
fffff880`0318c9a0 fffff880`012e0cc1 : 00000000`01010000 00000000`00000000 fffff800`02c68200 00000000`00000001 : Ntfs!NtfsDeleteScb+0x108
fffff880`0318c9e0 fffff880`0125985c : fffff8a0`07432830 fffff8a0`07432930 fffff800`02c68200 fffff880`0318cb52 : Ntfs!NtfsRemoveScb+0x61
fffff880`0318ca20 fffff880`012de64c : fffff8a0`07432800 fffff800`02c68260 fffff880`0318cb52 fffffa80`05afc2c0 : Ntfs!NtfsPrepareFcbForRemoval+0x50
fffff880`0318ca50 fffff880`012600e2 : fffffa80`05afc2c0 fffffa80`05afc2c0 fffff8a0`07432800 00000000`00000000 : Ntfs!NtfsTeardownStructures+0xdc
fffff880`0318cad0 fffff880`012ee193 : fffffa80`05afc2c0 fffff800`02c68260 fffff8a0`07432800 00000000`00000009 : Ntfs!NtfsDecrementCloseCounts+0xa2
fffff880`0318cb10 fffff880`012dd357 : fffffa80`05afc2c0 fffff8a0`07432930 fffff8a0`07432800 fffffa80`049d3180 : Ntfs!NtfsCommonClose+0x353
fffff880`0318cbe0 fffff800`02ad2001 : 00000000`00000000 fffff800`02dbe900 fffffa80`03a05b01 01ccb219`00000002 : Ntfs!NtfsFspClose+0x15f
fffff880`0318ccb0 fffff800`02d62fee : 01ccb219`d03c8e2c fffffa80`03a05b60 00000000`00000080 fffffa80`039ed040 : nt!ExpWorkerThread+0x111
fffff880`0318cd40 fffff800`02ab95e6 : fffff880`02f63180 fffffa80`03a05b60 fffff880`02f6dfc0 000c0000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`0318cd80 00000000`00000000 : fffff880`0318d000 fffff880`03187000 fffff880`0318c700 00000000`00000000 : nt!KxStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+45d8c
fffff800`02a736c4 cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+45d8c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3
FAILURE_BUCKET_ID: X64_0xFC_nt!_??_::FNODOBFM::_string_+45d8c
BUCKET_ID: X64_0xFC_nt!_??_::FNODOBFM::_string_+45d8c
Followup: MachineOwner
---------
-- 04 gru 2011, 16:54 --
Po odłączeniu którejkolwiek z dwóch kości pamięci wszystko wydaje się hulać. Oraz po zostawieniu obu kości ale odłączeniu dodatkowego dysku. Dziwaczne.