New
#1
BSOD dxgmms1.sys during video
Hi,
If someone can help me it would be great i've been stuck on this issue for quite some time.
I did a flash upgrade, installed a USB data device and installed a VPN client when i started getting a BSOD.
Since then i've removed all versions of flash, removed the USB data device, removed the VPN client, reinstalled with VPN client with the latest 64 bit installation.
I keep getting failures on either igdkmd64.sys or dxgmms1.sys depending on whether or not i'm using the latest video drivers or slightly older ones.
At the moment my system is failing on dxgmms1.sys using the video drivers recommend by dell if i do a search on service tag. If i go into device manager and update my driver by "right clicking" and updating it will start failing on igdkmd64.sys
I have no idea how to resolve this issue.
When do a memory scan there are no errors.
My system is a dell XPS L702X with windows 7.
Latest mini dump is:
Please help! lol.Code:Microsoft (R) Windows Debugger Version 6.2.8229.0 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\********\Documents\060112-23899-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 (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7600.16792.amd64fre.win7_gdr.110408-1633 Machine Name: Kernel base = 0xfffff800`02e4c000 PsLoadedModuleList = 0xfffff800`03089e50 Debug session time: Fri Jun 1 15:53:54.999 2012 (UTC + 2:00) System Uptime: 0 days 0:22:03.128 Loading Kernel Symbols ............................................................... ................................................................ ............................................. Loading User Symbols Loading unloaded module list ..... TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\oca.ini, error 2 TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2 ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7F, {8, 80050033, 406f8, fffff8800431a68b} TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2 Probably caused by : dxgmms1.sys ( dxgmms1!VidSchiUpdateCurrentIsrFrameTime+8f ) Followup: MachineOwner --------- 0: 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: 0000000080050033 Arg3: 00000000000406f8 Arg4: fffff8800431a68b Debugging Details: ------------------ TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2 BUGCHECK_STR: 0x7f_8 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT PROCESS_NAME: System CURRENT_IRQL: 9 LAST_CONTROL_TRANSFER: from fffff80002ebbc69 to fffff80002ebc700 STACK_TEXT: fffff800`00ba4d28 fffff800`02ebbc69 : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000406f8 : nt!KeBugCheckEx fffff800`00ba4d30 fffff800`02eba132 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff800`00ba4e70 fffff880`0431a68b : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 fffff880`0ea2dfe0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : dxgmms1!VidSchiUpdateCurrentIsrFrameTime+0x8f STACK_COMMAND: kb FOLLOWUP_IP: dxgmms1!VidSchiUpdateCurrentIsrFrameTime+8f fffff880`0431a68b ff156f290000 call qword ptr [dxgmms1!_imp_KeQueryPerformanceCounter (fffff880`0431d000)] SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: dxgmms1!VidSchiUpdateCurrentIsrFrameTime+8f FOLLOWUP_NAME: MachineOwner MODULE_NAME: dxgmms1 IMAGE_NAME: dxgmms1.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4d3fa174 FAILURE_BUCKET_ID: X64_0x7f_8_dxgmms1!VidSchiUpdateCurrentIsrFrameTime+8f BUCKET_ID: X64_0x7f_8_dxgmms1!VidSchiUpdateCurrentIsrFrameTime+8f Followup: MachineOwner ---------
I've just updated the drivers for my NVIDIA GeForce GT 555M to the latest version available on their site (301.42-notebook-win7-winvista-64bit-international-whql.exe).
The BSOD now fails on nvkflt.sys.
The mini dump is:
I Just checked the MEMORY.DMP it contains the following:Code:Microsoft (R) Windows Debugger Version 6.2.8229.0 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\*******\Documents\060112-29281-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 (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7600.16792.amd64fre.win7_gdr.110408-1633 Machine Name: Kernel base = 0xfffff800`02e55000 PsLoadedModuleList = 0xfffff800`03092e50 Debug session time: Fri Jun 1 17:51:17.808 2012 (UTC + 2:00) System Uptime: 0 days 0:16:31.344 Loading Kernel Symbols ............................................................... ................................................................ .............................................. Loading User Symbols Loading unloaded module list ..... TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\oca.ini, error 2 TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2 ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7F, {8, 80050033, 406f8, fffff88004089034} *** WARNING: Unable to verify timestamp for nvkflt.sys *** ERROR: Module load completed but symbols could not be loaded for nvkflt.sys TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2 Probably caused by : nvkflt.sys ( nvkflt+2d034 ) Followup: MachineOwner --------- 0: 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: 0000000080050033 Arg3: 00000000000406f8 Arg4: fffff88004089034 Debugging Details: ------------------ TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2 BUGCHECK_STR: 0x7f_8 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT PROCESS_NAME: System CURRENT_IRQL: 9 LAST_CONTROL_TRANSFER: from fffff80002ec4c69 to fffff80002ec5700 STACK_TEXT: fffff800`04418d28 fffff800`02ec4c69 : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000406f8 : nt!KeBugCheckEx fffff800`04418d30 fffff800`02ec3132 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff800`04418e70 fffff880`04089034 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 fffff880`2108bfb0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nvkflt+0x2d034 STACK_COMMAND: kb FOLLOWUP_IP: nvkflt+2d034 fffff880`04089034 e863faffff call nvkflt+0x2ca9c (fffff880`04088a9c) SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nvkflt+2d034 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nvkflt IMAGE_NAME: nvkflt.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4fb2078c FAILURE_BUCKET_ID: X64_0x7f_8_nvkflt+2d034 BUCKET_ID: X64_0x7f_8_nvkflt+2d034 Followup: MachineOwner ---------
Something is definitely messing with my video drivers, but i do not have the expertise to identify the culprit.Code:Microsoft (R) Windows Debugger Version 6.2.8229.0 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\******\Documents\MEMORY.DMP] Kernel Summary Dump File: Only kernel address space is available Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows 7 Kernel Version 7600 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7600.16792.amd64fre.win7_gdr.110408-1633 Machine Name: Kernel base = 0xfffff800`02e55000 PsLoadedModuleList = 0xfffff800`03092e50 Debug session time: Fri Jun 1 17:51:17.808 2012 (UTC + 2:00) System Uptime: 0 days 0:16:31.344 Loading Kernel Symbols ............................................................... ................................................................ .............................................. Loading User Symbols Loading unloaded module list ..... TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\oca.ini, error 2 TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2 TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\user.ini, error 2 ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7F, {8, 80050033, 406f8, fffff88004089034} *** ERROR: Module load completed but symbols could not be loaded for nvkflt.sys *** ERROR: Symbol file could not be found. Defaulted to export symbols for igdkmd64.sys - *** ERROR: Module load completed but symbols could not be loaded for vsdatant.sys *** ERROR: Module load completed but symbols could not be loaded for NETwNs64.sys TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2 Probably caused by : nvkflt.sys ( nvkflt+2d034 ) Followup: MachineOwner --------- 0: 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: 0000000080050033 Arg3: 00000000000406f8 Arg4: fffff88004089034 Debugging Details: ------------------ TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2 BUGCHECK_STR: 0x7f_8 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT PROCESS_NAME: System CURRENT_IRQL: 9 TRAP_FRAME: 0000000080000000 -- (.trap 0x80000000) Unable to read trap frame at ffffffff`80000000 LAST_CONTROL_TRANSFER: from fffff80002ec4c69 to fffff80002ec5700 STACK_TEXT: fffff800`04418d28 fffff800`02ec4c69 : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000406f8 : nt!KeBugCheckEx fffff800`04418d30 fffff800`02ec3132 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff800`04418e70 fffff880`04089034 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 fffff880`2108bfb0 fffff880`04085c39 : fffffa80`08863cd0 fffffa80`08863cd0 fffff880`2108c1b0 fffffa80`08994350 : nvkflt+0x2d034 fffff880`2108c040 fffff880`04075ed3 : fffff880`04085ba3 fffffa80`08994350 fffff880`2108c7e0 00000000`00000005 : nvkflt+0x29c39 fffff880`2108c0e0 fffff880`0491efbd : fffff880`04075e41 00000000`00000000 fffffa80`0bbd6000 fffffa80`0bbd6000 : nvkflt+0x19ed3 fffff880`2108c180 fffff880`048b558b : 00000000`00000001 00000000`00000000 fffff880`2108c7c0 fffff880`04a30f19 : igdkmd64!hybDriverEntry+0xf715d fffff880`2108c720 fffff880`0484cf75 : fffffa80`08c2d000 fffffa80`0884d790 00000000`00000000 00000000`00000001 : igdkmd64!hybDriverEntry+0x8d72b fffff880`2108c7a0 fffff880`0406acc7 : 00000000`00000000 fffffa80`08c2d000 00000000`00000000 fffff880`2108ca88 : igdkmd64!hybDriverEntry+0x25115 fffff880`2108c810 fffff880`04078f7b : fffff880`0406ac33 fffffa80`088522e0 fffffa80`08c2d000 fffffa80`08863990 : nvkflt+0xecc7 fffff880`2108c8b0 fffff880`0405eefe : fffff880`04078ee2 00000000`00000000 fffffa80`0884d310 00000000`00000001 : nvkflt+0x1cf7b fffff880`2108c960 fffff800`02ec14fc : fffff880`0405ee6b fffff880`2108cd50 fffff880`2108ca80 fffffa80`09b64e40 : nvkflt+0x2efe fffff880`2108ca00 fffff800`02ea0b86 : 00000000`00000000 fffff880`2108cc30 00000000`80000000 fffffa80`06f861bc : nt!KiInterruptDispatch+0x16c fffff880`2108cb90 fffff800`02e8dd8c : fffff880`2108cc70 fffffa80`089b5068 fffff880`2108d358 00000000`00000000 : nt!RtlSidHashInitialize+0x8a fffff880`2108cbc0 fffff800`02e8decf : fffffa80`089b5068 00000000`00000001 00000000`00000000 fffffa80`089b5068 : nt!SepTokenFromAccessInformation+0xbc fffff880`2108cbf0 fffff880`01406c5a : fffff880`2108d480 fffff880`01406c5a 00000000`00000000 00000000`00000000 : nt!SeAccessCheckFromState+0x9f fffff880`2108d2e0 fffff880`0140494f : 00000000`00000000 fffff880`00000001 00000000`c0000022 fffff880`0142d775 : NETIO!CompareSecurityContexts+0x6a fffff880`2108d350 fffff880`014069b5 : 00000000`00000001 fffffa80`0d316f20 00000000`00000003 fffff880`01508429 : NETIO!MatchValues+0xef fffff880`2108d3a0 fffff880`01406b30 : fffffa80`0cbcebe0 00000000`00000000 00000000`00000000 fffff880`2108d860 : NETIO!FilterMatch+0x95 fffff880`2108d3f0 fffff880`01407ccb : 00000000`00000003 00000000`00000030 fffffa80`07be1d40 fffff880`2108d860 : NETIO!IndexHashClassify+0xd0 fffff880`2108d480 fffff880`0163f417 : fffff880`2108d860 fffff880`2108d860 00000000`00000000 fffffa80`0d458670 : NETIO!KfdClassify+0xa4e fffff880`2108d7f0 fffff880`0164236d : fffffa80`07be1d40 fffffa80`09758300 fffff880`2108e3a8 fffffa80`0beb8e10 : tcpip!WfpAleClassify+0x57 fffff880`2108d830 fffff880`01642695 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000002 : tcpip!WfpAlepReauthorizeInboundConnection+0x60d fffff880`2108db30 fffff880`016715f1 : fffff880`2108dff0 00000020`00000001 00000000`00000011 fffffa80`0beb8e10 : tcpip!WfpAleReauthorizeInboundConnection+0x1f5 fffff880`2108dc90 fffff880`016611ef : 00000000`000007b1 00000000`00000001 fffffa80`0c7ea860 fffffa80`0beb8e10 : tcpip!WfpAleReauthorizeConnection+0x321 fffff880`2108df20 fffff880`0163e36a : fffffa80`09758300 fffffa80`07bd0002 00000000`00000000 00000000`00000100 : tcpip!TlShimOptionalReauthorizeConnection+0x2cf fffff880`2108e060 fffff880`0168073d : fffff880`2108e4b8 fffff880`01627ba4 00000000`00000000 fffffa80`0d458670 : tcpip!ProcessALEForTransportPacket+0x3ea fffff880`2108e2d0 fffff880`01640050 : fffffa80`09758300 00000000`00000000 00000000`00000002 00000000`00000025 : tcpip!ProcessAleForNonTcpIn+0x1ad fffff880`2108e3f0 fffff880`01670fe1 : fffffa80`00000011 fffffa80`0d570002 fffffa80`07d46c07 00000000`0000bad0 : tcpip!WfpProcessInTransportStackIndication+0xb10 fffff880`2108e760 fffff880`01640f63 : fffffa80`0d574010 fffffa80`07c29820 00000000`00000000 fffffa80`07d42138 : tcpip!InetInspectReceiveDatagram+0x121 fffff880`2108e800 fffff880`01641315 : fffffa80`0d574010 fffffa80`0cdd1180 fffffa80`06cdf788 fffff800`0303fe80 : tcpip!UdpBeginMessageIndication+0x83 fffff880`2108e950 fffff880`016418a4 : fffffa80`00000018 fffffa80`0d574010 00000000`00000000 fffff880`0678f0c8 : tcpip!UdpDeliverDatagrams+0xd5 fffff880`2108eae0 fffff880`0165f727 : fffffa80`07d55e30 00000000`00000000 fffffa80`0c7ea860 00000000`00000000 : tcpip!UdpReceiveDatagrams+0x324 fffff880`2108ebd0 fffff880`0165f799 : fffff880`2108ed50 fffff880`0176d9a0 fffff880`2108ed60 fffffa80`07bb7050 : tcpip!IppDeliverListToProtocol+0xf7 fffff880`2108ec90 fffff880`0165fc90 : fffff880`0176d9a0 fffffa80`0d4587a0 00000000`00000011 fffff880`2108ed50 : tcpip!IppProcessDeliverList+0x59 fffff880`2108ed00 fffff880`0165eb21 : 00000000`faffffef fffffa80`07d42138 fffff880`0176d9a0 00000000`0888e601 : tcpip!IppReceiveHeaderBatch+0x231 fffff880`2108ede0 fffff880`01736542 : fffffa80`0c7eb6d0 00000000`00000000 fffffa80`0888e601 00000000`00000001 : tcpip!IpFlcReceivePackets+0x651 fffff880`2108efe0 fffff880`01899afa : fffffa80`0cba3e02 fffffa80`0cba3ea0 00000000`00000002 00000000`00000000 : tcpip!IppInspectInjectReceive+0xf2 fffff880`2108f020 fffff880`02c12fa7 : fffffa80`0cb02820 fffffa80`0888e640 00000000`00000000 00000000`00000000 : fwpkclnt!FwpsInjectTransportReceiveAsync0+0x256 fffff880`2108f0d0 fffff880`02c123d0 : fffffa80`0888e640 fffffa80`06e2b010 fffff880`2108f900 fffffa80`0888e700 : vsdatant+0x12fa7 fffff880`2108f160 fffff880`02c0ddd1 : fffffa80`0888e640 fffffa80`0888e640 fffff880`2108f900 fffffa80`0888e738 : vsdatant+0x123d0 fffff880`2108f260 fffff880`0141d57f : fffff880`2108f878 fffff880`2108f990 fffffa80`0711d350 fffffa80`0cb35dd0 : vsdatant+0xddd1 fffff880`2108f390 fffff880`014074db : fffffa80`06dc0018 fffff880`2108f878 fffffa80`0beb8e68 fffffa80`0711d350 : NETIO! ?? ::FNODOBFM::`string'+0x7267 fffff880`2108f4b0 fffff880`01700fbb : fffff880`2108fec8 fffff880`2108f878 fffff880`2108fec8 fffffa80`0711d350 : NETIO!KfdClassify+0x24b fffff880`2108f820 fffff880`01604d10 : 00000000`00000000 fffffa80`09758300 fffffa80`0beb8f70 00000000`00000100 : tcpip!WFPDatagramDataShimV4+0x49b fffff880`2108fb80 fffff880`0168073d : fffff880`2108ffd8 fffff880`01627ba4 00000000`00000000 fffffa80`0711d350 : tcpip! ?? ::FNODOBFM::`string'+0x2b43f fffff880`2108fdf0 fffff880`01640050 : fffffa80`09758300 00000000`00000000 00000000`00000002 00000000`00000025 : tcpip!ProcessAleForNonTcpIn+0x1ad fffff880`2108ff10 fffff880`01670fe1 : fffffa80`00000011 fffffa80`0d570002 fffffa80`07d46c07 00000000`0000bad0 : tcpip!WfpProcessInTransportStackIndication+0xb10 fffff880`21090280 fffff880`01640f63 : fffffa80`0d574010 fffffa80`07c29820 00000000`00000000 fffffa80`07d42000 : tcpip!InetInspectReceiveDatagram+0x121 fffff880`21090320 fffff880`01641315 : fffffa80`0d574010 fffffa80`0cdd1180 fffff880`21090580 00000000`00000000 : tcpip!UdpBeginMessageIndication+0x83 fffff880`21090470 fffff880`016418a4 : fffffa80`00000018 fffffa80`0d574010 00000000`00000000 fffff880`0678f0c8 : tcpip!UdpDeliverDatagrams+0xd5 fffff880`21090600 fffff880`0165f727 : fffffa80`07d55e30 00000000`00000000 fffffa80`0c7ea860 00000000`00000000 : tcpip!UdpReceiveDatagrams+0x324 fffff880`210906f0 fffff880`0165f799 : fffff880`21090870 fffff880`0176d9a0 fffff880`21090880 fffffa80`07bb7050 : tcpip!IppDeliverListToProtocol+0xf7 fffff880`210907b0 fffff880`0165fc90 : fffff880`0176d9a0 fffffa80`08cfbd60 00000000`00000011 fffff880`21090870 : tcpip!IppProcessDeliverList+0x59 fffff880`21090820 fffff880`0165eb21 : fffffa80`faffffef fffffa80`07d42000 fffff880`0176d9a0 00000000`0c7dea01 : tcpip!IppReceiveHeaderBatch+0x231 fffff880`21090900 fffff880`0165d592 : fffffa80`0c7eb6d0 00000000`00000000 fffffa80`0c7dea01 00000000`00000001 : tcpip!IpFlcReceivePackets+0x651 fffff880`21090b00 fffff880`01676e5a : fffffa80`0c7deaa0 fffff880`21090c30 fffffa80`0c7deaa0 00000000`00000000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2 fffff880`21090be0 fffff800`02ed4e5a : fffffa80`0711d350 fffff880`2108c000 00000000`00004800 00000000`00000000 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0xda fffff880`21090c30 fffff880`01676882 : fffff880`01676d80 fffff880`21090d40 000000af`0408e602 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0xda fffff880`21090d10 fffff880`015c40eb : fffffa80`0c7dc220 00000000`00000000 fffffa80`08c3a1a0 fffffa80`08c3a1a0 : tcpip!FlReceiveNetBufferListChain+0xb2 fffff880`21090d80 fffff880`0158dfc6 : fffff880`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb fffff880`21090df0 fffff880`01510a24 : fffffa80`08c3a1a0 00000000`00000002 00000000`00000001 00001313`00001211 : ndis!ndisMDispatchReceiveNetBufferLists+0x1d6 fffff880`21091270 fffff880`015109e9 : 00000000`00000008 fffff880`01507fbf 00000000`00000000 00000000`00000000 : ndis!ndisMTopReceiveNetBufferLists+0x24 fffff880`210912b0 fffff880`01510980 : fffff880`0678f09e fffffa80`0c7a6010 ffff0000`23cf039f fffff880`02286355 : ndis!ndisFilterIndicateReceiveNetBufferLists+0x29 fffff880`210912f0 fffff880`02c1620d : fffffa80`0c7ca860 00000000`00000000 00000000`00000001 fffffa80`0711d350 : ndis!NdisFIndicateReceiveNetBufferLists+0x50 fffff880`21091330 fffff880`015109e9 : fffffa80`0c7ca860 fffffa80`0711d350 fffffa80`00000000 00000000`00000001 : vsdatant+0x1620d fffff880`210913d0 fffff880`01510980 : fffff880`022c05c0 fffffa80`0c7a6010 fffffa80`0c7ca020 00000000`00000001 : ndis!ndisFilterIndicateReceiveNetBufferLists+0x29 fffff880`21091410 fffff880`022897ee : fffffa80`0c7a6010 00000000`00000000 fffffa80`0711d350 fffff880`022c05c0 : ndis!NdisFIndicateReceiveNetBufferLists+0x50 fffff880`21091450 fffff880`015109e9 : fffffa80`096f2400 00000000`00000000 00000000`00000001 fffff880`05ed63b0 : nwifi!Pt6Receive+0x296 fffff880`210914b0 fffff880`01510980 : 00000000`00000001 fffff880`02df10bc fffffa80`096f8328 fffff880`00000018 : ndis!ndisFilterIndicateReceiveNetBufferLists+0x29 fffff880`210914f0 fffff880`02ded9c0 : fffff880`02df4110 00000000`00000001 00000000`00000001 fffffa80`096f8d78 : ndis!NdisFIndicateReceiveNetBufferLists+0x50 fffff880`21091530 fffff880`015282b7 : fffffa80`08c3a1a0 fffffa80`08cfbc30 fffffa80`08cfbc30 00000000`00000001 : vwififlt!FilterReceiveNetBufferLists+0x158 fffff880`21091590 fffff880`0589acc8 : fffffa80`08d7dd60 fffffa80`08cfbc30 00000000`00000000 00000000`00000001 : ndis! ?? ::FNODOBFM::`string'+0xccef fffff880`210915e0 fffff880`0589b205 : 00000000`00000001 fffffa80`0c6c4260 00000000`00000000 fffff880`21091760 : NETwNs64+0x1ddcc8 fffff880`21091640 fffff880`058991cd : fffff880`05ec8200 fffff880`05ec8270 fffff880`05ed00c1 00000000`00000000 : NETwNs64+0x1de205 STACK_COMMAND: kb FOLLOWUP_IP: nvkflt+2d034 fffff880`04089034 e863faffff call nvkflt+0x2ca9c (fffff880`04088a9c) SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nvkflt+2d034 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nvkflt IMAGE_NAME: nvkflt.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4fb2078c FAILURE_BUCKET_ID: X64_0x7f_8_nvkflt+2d034 BUCKET_ID: X64_0x7f_8_nvkflt+2d034 Followup: MachineOwner ---------
I've attached the .dmp files.
Last edited by voided; 01 Jun 2012 at 11:29. Reason: merged consecutive posts