See this link.
"0x00000008, or Double Fault, indicates that an exception occurs during a call to the handler for a prior exception. Typically, the two exceptions are handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. There are two common causes of a double fault:
- A kernel stack overflow. This overflow occurs when a guard page is hit, and the kernel tries to push a trap frame. Because there is no stack left, a stack overflow results, causing the double fault. If you think this overview has occurred, use the !thread debugger extension to determine the stack limits, and then use the kb (Display Stack Backtrace) debugger command with a large parameter (for example, kb 100) to display the full stack.
- A hardware problem."
Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [E:\Temp\Rar$DI00.265\110909-19874-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\SymCache*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.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a0e000 PsLoadedModuleList = 0xfffff800`02c4be50
Debug session time: Mon Nov 9 16:02:21.252 2009 (GMT-5)
System Uptime: 0 days 23:30:11.281
Loading Kernel Symbols
...............................................................
................................................................
.................................................
Loading User Symbols
Loading unloaded module list
..............................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80050031, 6f8, fffff80002a48798}
Unable to load image vsdatant.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for vsdatant.sys
*** ERROR: Module load completed but symbols could not be loaded for vsdatant.sys
Probably caused by : NETIO.SYS ( NETIO!CompareSecurityContexts+6a )
Followup: MachineOwner
---------
1: 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: fffff80002a48798
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 fffff80002a7f469 to fffff80002a7ff00
STACK_TEXT:
fffff880`009efc68 fffff800`02a7f469 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`009efc70 fffff800`02a7d932 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009efdb0 fffff800`02a48798 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff880`02f15dd0 fffff880`01606c5a : 445d8f3f`56843a4e 76b04c6b`a2486497 ca5a89c1`537eba51 65acdb62`9fd25e94 : nt!SeAccessCheckFromState+0x58
fffff880`02f164c0 fffff880`0160494f : f9def9f9`ddfbfbdd e5f3f3e3`f6f6e2f9 d2a3e0d0`a3e1e6dc a9e3d5a3`e2d5a5e1 : NETIO!CompareSecurityContexts+0x6a
fffff880`02f16530 fffff880`016069b5 : ffffaaff`ffb3ffff ffadffff`a5ffffa3 a5f5ffaa`fdffafff edfdb0f4`ffaef0ff : NETIO!MatchValues+0xef
fffff880`02f16580 fffff880`01606845 : fffffa80`0707b110 fffffa80`03fc9250 fffff880`02f167a8 fffff880`02f16ee0 : NETIO!FilterMatch+0x95
fffff880`02f165d0 fffff880`01607ccb : 00000000`00000000 00000000`00000000 fffff880`02f16ee0 fffff880`02f16790 : NETIO!IndexListClassify+0x69
fffff880`02f16650 fffff880`0183d4d0 : fffff880`02f16ee0 fffff880`02f16b28 fffff880`02f17860 fffffa80`074f9ac0 : NETIO!KfdClassify+0xa4e
fffff880`02f169c0 fffff880`0183677e : fffff880`01945690 00000000`00000000 fffffa80`07b13360 00000000`00000000 : tcpip!WfpAleClassify+0x50
fffff880`02f16a00 fffff880`01835c15 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!WfpAlepAuthorizeSend+0x94e
fffff880`02f17110 fffff880`01839956 : 00000000`00000000 00000000`00000000 00000000`00000011 00000000`00000000 : tcpip!WfpAleAuthorizeSend+0x325
fffff880`02f173e0 fffff880`0183c6a4 : 00000000`00000000 fffff880`02f17818 fffff880`02f17820 00000000`00000000 : tcpip!WfpAleConnectAcceptIndicate+0x106
fffff880`02f174d0 fffff880`01834f59 : fffff880`041313c0 00000000`000000ff 00000000`00000001 00000000`00000008 : tcpip!ProcessALEForTransportPacket+0x664
fffff880`02f17740 fffff880`01861bf6 : 00000000`00000000 00000000`00000002 fffffa80`05268900 fffffa80`05f015e6 : tcpip!WfpProcessOutTransportStackIndication+0x329
fffff880`02f17910 fffff880`01866a7e : fffffa80`05265190 fffff880`01602804 fffff880`0196b9a0 fffffa80`07b13360 : tcpip!IppSendDatagramsCommon+0x526
fffff880`02f17be0 fffff880`01833cf8 : fffffa80`07b13360 fffffa80`074f9ac0 fffffa80`074f9ac0 fffffa80`05265190 : tcpip!IpNlpSendDatagrams+0x3e
fffff880`02f17c20 fffff880`0183426d : fffffa80`052c3680 fffffa80`07143bc0 fffff880`02f18570 00000000`00000000 : tcpip!UdpSendMessagesOnPathCreation+0x688
fffff880`02f17fa0 fffff880`01833ef5 : fffff880`02f184d0 fffffa80`04a315e6 fffff880`00000001 fffffa80`05f0b0f0 : tcpip!UdpSendMessages+0x35d
fffff880`02f18390 fffff800`02a8f64a : fffff880`02f18720 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
fffff880`02f183c0 fffff880`018344b8 : fffff880`01833ee0 fffff880`02f184d0 00000000`00000002 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0xda
fffff880`02f184a0 fffff880`02d3bf45 : fffffa80`04107f90 fffffa80`06d0fe10 fffffa80`05f82390 fffffa80`07d4f9ee : tcpip!UdpTlProviderSendMessages+0x78
fffff880`02f18520 fffff880`02d3bff2 : fffffa80`04bf1502 fffffa80`072991d0 fffffa80`04287e48 fffffa80`072991d0 : tdx!TdxSendDatagramTransportAddress+0x2f5
fffff880`02f18600 fffff880`03f91542 : 00000000`00000000 fffffa80`06af1ba0 00000000`00000000 fffffa80`04287d30 : tdx!TdxTdiDispatchInternalDeviceControl+0x52
fffff880`02f18630 fffff880`03f91f61 : fffffa80`07d4f9b8 fffffa80`07d4f9b8 fffffa80`076ecaa0 fffff880`02f18730 : netbt!TdiSendDatagram+0x187
fffff880`02f186a0 fffff880`03f9e329 : fffffa80`05fae250 fffffa80`07d4f800 00000000`00000021 00000000`0000003e : netbt!UdpSendDatagram+0x1b1
fffff880`02f18730 fffff880`03f9e0e6 : 00000000`00000000 00000000`00000000 00000000`00000032 fffff880`03fbe615 : netbt!UdpSendResponse+0x4e0
fffff880`02f187b0 fffff880`03f92be7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : netbt!QueryFromNet+0xb11
fffff880`02f188e0 fffff880`03f90b47 : 00000000`00000032 fffff880`033d9084 00000000`00000032 fffffa80`05f82302 : netbt!NameSrvHndlrNotOs+0xca
fffff880`02f18920 fffff880`02d3a325 : fffffa80`07303080 fffffa80`03c30002 fffff880`02f18c28 fffffa80`07303080 : netbt!TdiRcvNameSrvHandler+0x367
fffff880`02f189c0 fffff880`0183f3c5 : fffffa80`03c3b6d0 00000000`00000000 fffffa80`03c3b6d0 fffffa80`03c3b6d0 : tdx!TdxEventReceiveMessagesTransportAddress+0x315
fffff880`02f18bb0 fffff880`0183f8d4 : fffffa80`00000000 fffffa80`03c3b6d0 00000000`00000000 fffff880`033d907c : tcpip!UdpDeliverDatagrams+0x155
fffff880`02f18d40 fffff880`0185b427 : fffffa80`0413ede0 fffff880`00000000 fffffa80`05221010 00000000`00000000 : tcpip!UdpReceiveDatagrams+0x324
fffff880`02f18e30 fffff880`0185b499 : fffff880`02f18fb0 fffff880`0196b9a0 fffff880`02f18fc0 fffffa80`040ee110 : tcpip!IppDeliverListToProtocol+0xf7
fffff880`02f18ef0 fffff880`0185b990 : fffff880`0196b9a0 fffffa80`04a3d390 00000000`00000011 fffff880`02f18fb0 : tcpip!IppProcessDeliverList+0x59
fffff880`02f18f60 fffff880`0185a821 : 00000000`ff0c140a fffffa80`04146138 fffff880`0196b9a0 00000000`04e68901 : tcpip!IppReceiveHeaderBatch+0x231
fffff880`02f19040 fffff880`01934592 : fffffa80`0520ae50 00000000`00000000 fffffa80`04e68901 fffffa80`00000001 : tcpip!IpFlcReceivePackets+0x651
fffff880`02f19240 fffff880`01694afa : fffffa80`07ca8002 fffffa80`07ca8010 00000000`00000002 00000000`00000000 : tcpip!IppInspectInjectReceive+0xf2
fffff880`02f19280 fffff880`040c4863 : fffffa80`071e8540 fffffa80`04e689c0 00000000`00000000 00000000`00000000 : fwpkclnt!FwpsInjectTransportReceiveAsync0+0x256
fffff880`02f19330 fffffa80`071e8540 : fffffa80`04e689c0 00000000`00000000 00000000`00000000 00000000`00000002 : vsdatant+0x15863
fffff880`02f19338 fffffa80`04e689c0 : 00000000`00000000 00000000`00000000 00000000`00000002 00000000`00000001 : 0xfffffa80`071e8540
fffff880`02f19340 00000000`00000000 : 00000000`00000000 00000000`00000002 00000000`00000001 fffffa80`0000000c : 0xfffffa80`04e689c0
STACK_COMMAND: kb
FOLLOWUP_IP:
NETIO!CompareSecurityContexts+6a
fffff880`01606c5a 448b442470 mov r8d,dword ptr [rsp+70h]
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: NETIO!CompareSecurityContexts+6a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: NETIO
IMAGE_NAME: NETIO.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc18a
FAILURE_BUCKET_ID: X64_0x7f_8_NETIO!CompareSecurityContexts+6a
BUCKET_ID: X64_0x7f_8_NETIO!CompareSecurityContexts+6a
Followup: MachineOwner
---------
So, only thing I recommend is what I did already. "Install the latest driver you can find for your motherboard's lan adapter and update any VPN software you may be using." Also, update the wifi adapter driver if possible, too.
Update this software if one is available, or remove if possible: "WDSmartWare.exe" http://www.wdc.com/wdproducts/update...ly=wdsmartware
Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [E:\Temp\Rar$DI01.250\110609-20701-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\SymCache*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.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a66000 PsLoadedModuleList = 0xfffff800`02ca3e50
Debug session time: Fri Nov 6 13:18:36.045 2009 (GMT-5)
System Uptime: 0 days 0:03:08.058
Loading Kernel Symbols
...............................................................
................................................................
.........................................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80050031, 6f8, fffff80002ae234f}
Probably caused by : NETIO.SYS ( NETIO!CompareSecurityContexts+6a )
Followup: MachineOwner
---------
1: 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: fffff80002ae234f
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: WDSmartWare.ex
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff80002ad7469 to fffff80002ad7f00
STACK_TEXT:
fffff880`009efc68 fffff800`02ad7469 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`009efc70 fffff800`02ad5932 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009efdb0 fffff800`02ae234f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff880`02f1cfc0 fffff800`02add5a7 : fffff880`02f1d180 fffff880`02f1d1a0 00000000`00000001 00000000`00000000 : nt!SepMandatoryIntegrityCheck+0x4f
fffff880`02f1d040 fffff800`02aa0842 : fffffa80`07c2d080 00000000`00000001 00000000`00000000 fffffa80`04268068 : nt!SeAccessCheckWithHint+0x317
fffff880`02f1d120 fffff880`01594c5a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!SeAccessCheckFromState+0x102
fffff880`02f1d810 fffff880`0159294f : 00000000`c0000022 00000000`00000000 00000000`00000000 00000000`00000000 : NETIO!CompareSecurityContexts+0x6a
fffff880`02f1d880 fffff880`015949b5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : NETIO!MatchValues+0xef
fffff880`02f1d8d0 fffff880`01594845 : fffffa80`069b1160 fffffa80`07a98760 fffff880`02f1daf8 fffff880`02f1e230 : NETIO!FilterMatch+0x95
fffff880`02f1d920 fffff880`01595ccb : 00000000`00000000 00000000`00000000 fffff880`02f1e230 fffff880`02f1dae0 : NETIO!IndexListClassify+0x69
fffff880`02f1d9a0 fffff880`0163d4d0 : fffff880`02f1e230 fffff880`02f1de78 fffff880`02f1ebb0 fffffa80`0795e5a0 : NETIO!KfdClassify+0xa4e
fffff880`02f1dd10 fffff880`0163677e : fffff880`01745690 00000000`00000000 fffffa80`07734db0 00000000`00000000 : tcpip!WfpAleClassify+0x50
fffff880`02f1dd50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!WfpAlepAuthorizeSend+0x94e
STACK_COMMAND: kb
FOLLOWUP_IP:
NETIO!CompareSecurityContexts+6a
fffff880`01594c5a 448b442470 mov r8d,dword ptr [rsp+70h]
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: NETIO!CompareSecurityContexts+6a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: NETIO
IMAGE_NAME: NETIO.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc18a
FAILURE_BUCKET_ID: X64_0x7f_8_NETIO!CompareSecurityContexts+6a
BUCKET_ID: X64_0x7f_8_NETIO!CompareSecurityContexts+6a
Followup: MachineOwner
---------
Perhaps update the bios on the machine, if possible.