Log in
Register
What's new
Search
Search
Search titles only
By:
Menu
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums
Tutorials
About
Rules
What's New
Driver Reference Table
Donate
Search titles only
By:
Latest activity
Register
Microsoft Support & Malware Removal
BSOD Crashes, Kernel Debugging
X58A-UD3R rev 2.0 Win7 BSOD i7 950 no overclock
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Patrick" data-source="post: 59387" data-attributes="member: 208"><p>Okay, this is actually good. We aren't getting *101's with the verifier enabled. I just wanted you to set it to Kernel just in case we'd get *101's so we can get right to analysis. Don't change it back, keep it on Kernel just in case we need it.</p><p></p><p>Right, so we have two dumps. The first bug check is of the <u><strong>IRQL_NOT_LESS_OR_EQUAL (a)</strong></u> bug check.</p><p></p><p><em>This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above.</em></p><p></p><p>This bug check is issued if paged memory (or invalid memory) is accessed when the IRQL is too high. The error that generates this bug check usually occurs after the installation of a faulty device driver, system service, or BIOS.</p><p></p><p><strong><em>If we take a look at the call stack:</em></strong></p><p><strong><em></em></strong></p><p><strong><em></em></strong></p><p><strong><em></em></strong>[CODE]0: kd> kv</p><p>Child-SP RetAddr : Args to Child : Call Site</p><p>fffff880`08088548 fffff800`03493169 : 00000000`0000000a fffff980`01384fd8 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx</p><p>fffff880`08088550 fffff800`03491de0 : 00000000`00000007 fffffa80`0d521050 00000000`00000000 fffffa80`0d521050 : nt!KiBugCheckDispatch+0x69</p><p>fffff880`08088690 fffff800`0355e588 : fffffa80`0d521050 00000000`00000000 fffff980`01384fa0 fffff880`080888c0 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`08088690)</p><p>fffff880`08088820 fffff880`04a78289 : 00000000`00000000 fffffa80`0e813880 fffff980`01384fa0 00000000`00000246 : nt!IoEnumerateDeviceObjectList+0x68</p><p>fffff880`08088860 fffff880`04a75a9c : 00000000`0000000c fffffa80`0e813880 fffffa80`0e813880 00000000`00000801 : <span style="color: #ff0000"><em><strong>hcmon</strong></em></span>+0x6289</p><p>fffff880`080888c0 fffff880`04a76136 : 00000000`00000000 00000000`81012368 fffffa80`0e3e8810 fffffa80`0da72130 : <span style="color: #ff0000"><em><strong>hcmon</strong></em></span>+0x3a9c</p><p>fffff880`08088930 fffff800`0393cd26 : fffffa80`0da72130 00000000`00000009 fffffa80`0da72130 fffffa80`0da72130 : <span style="color: #ff0000"><em><strong>hcmon</strong></em></span>+0x4136</p><p>fffff880`080889b0 fffff800`037b03a7 : fffffa80`0e6aa340 fffff880`08088ca0 fffffa80`0e6aa340 fffffa80`0da95010 : nt!IovCallDriver+0x566</p><p>fffff880`08088a10 fffff800`037b0c06 : 00000000`00000001 00000000`00000160 00000000`00000000 00000001`3f4fac40 : nt!IopXxxControlFile+0x607</p><p>fffff880`08088b40 fffff800`03492e53 : fffffa80`0e73e060 fffff880`08088ca0 fffff880`746c6644 fffff880`08088c38 : nt!NtDeviceIoControlFile+0x56</p><p>fffff880`08088bb0 00000000`7728132a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`08088c20)</p><p>00000000`0161f2e8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7728132a[/CODE]</p><p></p><p>We can see that the driver <strong><em>hcmon.sys </em></strong>(VMware USB monitor) was called three times, and right after we have a <strong><em>IoEnumerateDeviceObjectList </em></strong>routine call which enumerates a driver's device object list. This likely explains as to why we see it being called three times. Right after we have the pagefault and then the bug check itself.</p><p></p><p>It's a verifier enabled dump - FAILURE_BUCKET_ID: X64_0xA_<span style="color: #ff0000"><em><strong>VRF</strong></em></span>_<span style="color: #ff0000"><em><strong>hcmon</strong></em>+6289</span></p><p></p><p>VRF determines that, and the bolded in red right after that if we look at the call stack is one of our hcmon calls (the last one).</p><p></p><p><u><strong>---------------------------------------------------------------</strong></u></p><p></p><p>Check for any VMware updates - <a href="http://www.vmware.com/support/" target="_blank">VMware Support & Downloads for Desktop, Application & Data Center Virtualization | United States</a></p><p></p><p>If there aren't any, I'd suggest removing the software entirely for temporary troubleshooting purposes.</p><p></p><p><u><strong>---------------------------------------------------------------</strong></u></p><p><u><strong></strong></u></p><p><u><strong></strong></u></p><p><u><strong></strong></u>Moving on, the next bug check is of the <strong>DRIVER_VERIFIER_DETECTED_VIOLATION (c4)</strong> bug check.</p><p></p><p><em>This is the general bug check code for fatal errors found by Driver Verifier.</em></p><p></p><p><strong><em>If we look at the call stack:</em></strong></p><p><strong><em></em></strong></p><p><strong><em></em></strong></p><p><strong><em></em></strong>[CODE]4: kd> kv</p><p>Child-SP RetAddr : Args to Child : Call Site</p><p>fffff880`0bc4eb78 fffff800`0391c4ec : 00000000`000000c4 00000000`000000f6 00000000`000001b0 fffffa80`0a5d0b30 : nt!KeBugCheckEx</p><p>fffff880`0bc4eb80 fffff800`03931bf4 : 00000000`000001b0 fffffa80`0a5d0b30 00000000`00000004 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0x3c</p><p>fffff880`0bc4ebc0 fffff800`036e9890 : 00000000`0000000d fffff880`0bc4ee10 fffff880`0bc4ef00 fffff880`0bc4f0c8 : nt!<span style="color: #ff0000"><em><strong>VfCheckUserHandle</strong></em></span>+0x1b4</p><p>fffff880`0bc4eca0 fffff800`037431a5 : fffff8a0`0146da00 00000000`00000002 fffffa80`0973d420 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x2027e</p><p>fffff880`0bc4ed70 fffff800`0348ee53 : 00000000`000001b0 00000000`00000240 00000000`00000000 00000000`00000003 : nt!NtSetValueKey+0xe1</p><p>fffff880`0bc4eea0 fffff800`0348b410 : fffff800`039204db fffff880`04d595d1 fffff880`0bc4fafc 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0bc4ef10)</p><p>fffff880`0bc4f0a8 fffff800`039204db : fffff880`04d595d1 fffff880`0bc4fafc 00000000`00000000 fffff800`0348b410 : nt!KiServiceLinkage</p><p>fffff880`0bc4f0b0 fffff880`04d595d1 : 00000000`00000008 fffff880`0bc4f171 00000000`00000013 ffffffff`80000f80 : nt!<span style="color: #ff0000"><em><strong>VfZwSetValueKey</strong></em></span>+0x6b</p><p>fffff880`0bc4f100 fffff880`04d59129 : 00000000`00000004 fffff880`0bc4fafc 00000000`00000004 00000000`00000004 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>+0x995d1</p><p>fffff880`0bc4f1c0 fffff880`04da0f87 : fffff880`04d59098 fffff880`0bc4f9c0 fffff880`0bc4f400 fffff880`0bc4f9f8 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>+0x99129</p><p>fffff880`0bc4f260 fffff880`04d7124f : fffff880`0bc4f3c0 00000000`00074e53 00000000`80000000 fffffa80`0a5eb060 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>+0xe0f87</p><p>fffff880`0bc4f2b0 fffff880`04d64c00 : fffff880`0bc4f6c8 fffff880`0bc4f380 fffff880`0bc4f400 fffff800`0349c1f8 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>+0xb124f</p><p>fffff880`0bc4f300 fffff880`0553bb8f : 00000000`00000010 fffff880`0553bab0 00000000`00000010 00000000`00010286 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>+0xa4c00</p><p>fffff880`0bc4f5e0 fffff880`04d640ac : fffff880`051ba300 fffff880`0bc4f6d9 fffffa80`0d2ff000 00000000`00000000 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>!nvDumpConfig+0x24b7cf</p><p>fffff880`0bc4f620 fffff880`05520945 : fffff880`0bc4f950 fffff880`0bc4f7a9 fffff880`0bc4f950 fffff880`0bc4f950 : <span style="color: #ff0000"><em><strong>nvlddmkm</strong></em></span>+0xa40ac</p><p>fffff880`0bc4f740 fffff880`055b0899 : 00000000`00000000 00000000`00000000 00000000`4e562a2a 00000000`01000003 : <span style="color: #ff0000"><em><strong>nvlddmkm!nvDumpConfig</strong></em></span>+0x230585</p><p>fffff880`0bc4f810 fffff880`05a4ef50 : 00000000`00000000 00000000`00000000 fffff880`0bc4f950 00000000`00000018 : <span style="color: #ff0000"><em><strong>nvlddmkm!nvDumpConfig</strong></em></span>+0x2c04d9</p><p>fffff880`0bc4f840 fffff880`05a42093 : 00000000`00000000 00000000`00000000 fffff880`0bc4fca0 00000000`00000003 : <span style="color: #ff0000"><strong><em>dxgkrnl!DXGADAPTER</em></strong></span>::<span style="color: #ff0000"><em><strong>DdiEscape</strong></em></span>+0x50</p><p>fffff880`0bc4f870 fffff960`00271b32 : 00000000`6201123d fffffa80`0a5eb060 00000000`00388e30 00000000`00000020 : <span style="color: #ff0000"><em><strong>dxgkrnl!DxgkEscape</strong></em></span>+0x7af</p><p>fffff880`0bc4fbf0 fffff800`0348ee53 : fffffa80`0a5eb060 fffff880`00000000 00000000`00000000 00000000`00000000 : win32k!NtGdiDdDDIEscape+0x12</p><p>fffff880`0bc4fc20 000007fe`fee913ea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0bc4fc20)</p><p>00000000`0012d538 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007fe`fee913ea[/CODE]</p><p></p><p>Okay, so...</p><p></p><p>We start with a few DirectX Kernel Dxgk / Ddi calls. This is pretty advanced and I am not exactly sure what Escape implies, but the Ddi is the Device Driver Interface. Pair this along with the DirectX Kernel, and I can only imagine that the graphics driver is using it to control the output, as a graphics driver must ensure that its graphics device produces the required output.</p><p></p><p>We then see various <em><strong>nvlddmkm.sys</strong></em> (nVidia video driver) calls. Again, I am unsure as to what <strong><em>nvDumpConfig </em></strong>implies. After the nVidia video driver calls, we hit <strong><em>VfZwSetValueKey </em></strong>which creates or replaces a registry key's value entry. Two more calls up and we have <strong><em>NtSetValueKey </em></strong>which is the same call only the Nt indicates that it occurred in user-mode. We then see the <strong><em>VfCheckUserHandle </em></strong>call. If I am correct in my analysis, this indicates that a handle that was visible to user-mode was accessed in kernel-mode and does NOT have an OBJ_KERNEL_HANDLE attribute set. If a driver forgot to specify OBJ_KERNEL_HANDLE when creating a handle, it will end up creating a user-mode handle which in most cases is bad because user-mode code can now access the object than it may or may not have had access to otherwise.</p><p></p><p>If we take a look at our failure bucket ID - <em>FAILURE_BUCKET_ID: X64_0xc4_f6_<span style="color: #ff0000"><strong>VRF</strong></span>_<span style="color: #ff0000"><strong>nvlddmkm+995d1</strong></span></em></p><p></p><p>We can see that the nVidia video driver was blamed. Given all the DirectX Kernel calls leaves me curious about your RAM as well, although we'll worry about that if we have to. For now, ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.</p><p></p><p><u><strong>---------------------------------------------------------------------------------------------</strong></u></p><p></p><p><em><strong>E1G6032E.sys - Wed May 28 19:14:51 <u><span style="color: #ff0000">2008</span></u></strong></em></p><p></p><p>^^ Intel Ethernet drivers, pretty old. I'd check for an update - <a href="http://downloadcenter.intel.com/Default.aspx" target="_blank">http://downloadcenter.intel.com/Default.aspx</a></p><p></p><p>Regards,</p><p></p><p>Patrick</p></blockquote><p></p>
[QUOTE="Patrick, post: 59387, member: 208"] Okay, this is actually good. We aren't getting *101's with the verifier enabled. I just wanted you to set it to Kernel just in case we'd get *101's so we can get right to analysis. Don't change it back, keep it on Kernel just in case we need it. Right, so we have two dumps. The first bug check is of the [U][B]IRQL_NOT_LESS_OR_EQUAL (a)[/B][/U] bug check. [I]This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above.[/I] This bug check is issued if paged memory (or invalid memory) is accessed when the IRQL is too high. The error that generates this bug check usually occurs after the installation of a faulty device driver, system service, or BIOS. [B][I]If we take a look at the call stack: [/I][/B][CODE]0: kd> kv Child-SP RetAddr : Args to Child : Call Site fffff880`08088548 fffff800`03493169 : 00000000`0000000a fffff980`01384fd8 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`08088550 fffff800`03491de0 : 00000000`00000007 fffffa80`0d521050 00000000`00000000 fffffa80`0d521050 : nt!KiBugCheckDispatch+0x69 fffff880`08088690 fffff800`0355e588 : fffffa80`0d521050 00000000`00000000 fffff980`01384fa0 fffff880`080888c0 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`08088690) fffff880`08088820 fffff880`04a78289 : 00000000`00000000 fffffa80`0e813880 fffff980`01384fa0 00000000`00000246 : nt!IoEnumerateDeviceObjectList+0x68 fffff880`08088860 fffff880`04a75a9c : 00000000`0000000c fffffa80`0e813880 fffffa80`0e813880 00000000`00000801 : [COLOR=#ff0000][I][B]hcmon[/B][/I][/COLOR]+0x6289 fffff880`080888c0 fffff880`04a76136 : 00000000`00000000 00000000`81012368 fffffa80`0e3e8810 fffffa80`0da72130 : [COLOR=#ff0000][I][B]hcmon[/B][/I][/COLOR]+0x3a9c fffff880`08088930 fffff800`0393cd26 : fffffa80`0da72130 00000000`00000009 fffffa80`0da72130 fffffa80`0da72130 : [COLOR=#ff0000][I][B]hcmon[/B][/I][/COLOR]+0x4136 fffff880`080889b0 fffff800`037b03a7 : fffffa80`0e6aa340 fffff880`08088ca0 fffffa80`0e6aa340 fffffa80`0da95010 : nt!IovCallDriver+0x566 fffff880`08088a10 fffff800`037b0c06 : 00000000`00000001 00000000`00000160 00000000`00000000 00000001`3f4fac40 : nt!IopXxxControlFile+0x607 fffff880`08088b40 fffff800`03492e53 : fffffa80`0e73e060 fffff880`08088ca0 fffff880`746c6644 fffff880`08088c38 : nt!NtDeviceIoControlFile+0x56 fffff880`08088bb0 00000000`7728132a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`08088c20) 00000000`0161f2e8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7728132a[/CODE] We can see that the driver [B][I]hcmon.sys [/I][/B](VMware USB monitor) was called three times, and right after we have a [B][I]IoEnumerateDeviceObjectList [/I][/B]routine call which enumerates a driver's device object list. This likely explains as to why we see it being called three times. Right after we have the pagefault and then the bug check itself. It's a verifier enabled dump - FAILURE_BUCKET_ID: X64_0xA_[COLOR=#ff0000][I][B]VRF[/B][/I][/COLOR]_[COLOR=#ff0000][I][B]hcmon[/B][/I]+6289[/COLOR] VRF determines that, and the bolded in red right after that if we look at the call stack is one of our hcmon calls (the last one). [U][B]---------------------------------------------------------------[/B][/U] Check for any VMware updates - [url=http://www.vmware.com/support/]VMware Support & Downloads for Desktop, Application & Data Center Virtualization | United States[/url] If there aren't any, I'd suggest removing the software entirely for temporary troubleshooting purposes. [U][B]--------------------------------------------------------------- [/B][/U]Moving on, the next bug check is of the [B]DRIVER_VERIFIER_DETECTED_VIOLATION (c4)[/B] bug check. [I]This is the general bug check code for fatal errors found by Driver Verifier.[/I] [B][I]If we look at the call stack: [/I][/B][CODE]4: kd> kv Child-SP RetAddr : Args to Child : Call Site fffff880`0bc4eb78 fffff800`0391c4ec : 00000000`000000c4 00000000`000000f6 00000000`000001b0 fffffa80`0a5d0b30 : nt!KeBugCheckEx fffff880`0bc4eb80 fffff800`03931bf4 : 00000000`000001b0 fffffa80`0a5d0b30 00000000`00000004 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0x3c fffff880`0bc4ebc0 fffff800`036e9890 : 00000000`0000000d fffff880`0bc4ee10 fffff880`0bc4ef00 fffff880`0bc4f0c8 : nt![COLOR=#ff0000][I][B]VfCheckUserHandle[/B][/I][/COLOR]+0x1b4 fffff880`0bc4eca0 fffff800`037431a5 : fffff8a0`0146da00 00000000`00000002 fffffa80`0973d420 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x2027e fffff880`0bc4ed70 fffff800`0348ee53 : 00000000`000001b0 00000000`00000240 00000000`00000000 00000000`00000003 : nt!NtSetValueKey+0xe1 fffff880`0bc4eea0 fffff800`0348b410 : fffff800`039204db fffff880`04d595d1 fffff880`0bc4fafc 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0bc4ef10) fffff880`0bc4f0a8 fffff800`039204db : fffff880`04d595d1 fffff880`0bc4fafc 00000000`00000000 fffff800`0348b410 : nt!KiServiceLinkage fffff880`0bc4f0b0 fffff880`04d595d1 : 00000000`00000008 fffff880`0bc4f171 00000000`00000013 ffffffff`80000f80 : nt![COLOR=#ff0000][I][B]VfZwSetValueKey[/B][/I][/COLOR]+0x6b fffff880`0bc4f100 fffff880`04d59129 : 00000000`00000004 fffff880`0bc4fafc 00000000`00000004 00000000`00000004 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0x995d1 fffff880`0bc4f1c0 fffff880`04da0f87 : fffff880`04d59098 fffff880`0bc4f9c0 fffff880`0bc4f400 fffff880`0bc4f9f8 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0x99129 fffff880`0bc4f260 fffff880`04d7124f : fffff880`0bc4f3c0 00000000`00074e53 00000000`80000000 fffffa80`0a5eb060 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xe0f87 fffff880`0bc4f2b0 fffff880`04d64c00 : fffff880`0bc4f6c8 fffff880`0bc4f380 fffff880`0bc4f400 fffff800`0349c1f8 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xb124f fffff880`0bc4f300 fffff880`0553bb8f : 00000000`00000010 fffff880`0553bab0 00000000`00000010 00000000`00010286 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xa4c00 fffff880`0bc4f5e0 fffff880`04d640ac : fffff880`051ba300 fffff880`0bc4f6d9 fffffa80`0d2ff000 00000000`00000000 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]!nvDumpConfig+0x24b7cf fffff880`0bc4f620 fffff880`05520945 : fffff880`0bc4f950 fffff880`0bc4f7a9 fffff880`0bc4f950 fffff880`0bc4f950 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xa40ac fffff880`0bc4f740 fffff880`055b0899 : 00000000`00000000 00000000`00000000 00000000`4e562a2a 00000000`01000003 : [COLOR=#ff0000][I][B]nvlddmkm!nvDumpConfig[/B][/I][/COLOR]+0x230585 fffff880`0bc4f810 fffff880`05a4ef50 : 00000000`00000000 00000000`00000000 fffff880`0bc4f950 00000000`00000018 : [COLOR=#ff0000][I][B]nvlddmkm!nvDumpConfig[/B][/I][/COLOR]+0x2c04d9 fffff880`0bc4f840 fffff880`05a42093 : 00000000`00000000 00000000`00000000 fffff880`0bc4fca0 00000000`00000003 : [COLOR=#ff0000][B][I]dxgkrnl!DXGADAPTER[/I][/B][/COLOR]::[COLOR=#ff0000][I][B]DdiEscape[/B][/I][/COLOR]+0x50 fffff880`0bc4f870 fffff960`00271b32 : 00000000`6201123d fffffa80`0a5eb060 00000000`00388e30 00000000`00000020 : [COLOR=#ff0000][I][B]dxgkrnl!DxgkEscape[/B][/I][/COLOR]+0x7af fffff880`0bc4fbf0 fffff800`0348ee53 : fffffa80`0a5eb060 fffff880`00000000 00000000`00000000 00000000`00000000 : win32k!NtGdiDdDDIEscape+0x12 fffff880`0bc4fc20 000007fe`fee913ea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0bc4fc20) 00000000`0012d538 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007fe`fee913ea[/CODE] Okay, so... We start with a few DirectX Kernel Dxgk / Ddi calls. This is pretty advanced and I am not exactly sure what Escape implies, but the Ddi is the Device Driver Interface. Pair this along with the DirectX Kernel, and I can only imagine that the graphics driver is using it to control the output, as a graphics driver must ensure that its graphics device produces the required output. We then see various [I][B]nvlddmkm.sys[/B][/I] (nVidia video driver) calls. Again, I am unsure as to what [B][I]nvDumpConfig [/I][/B]implies. After the nVidia video driver calls, we hit [B][I]VfZwSetValueKey [/I][/B]which creates or replaces a registry key's value entry. Two more calls up and we have [B][I]NtSetValueKey [/I][/B]which is the same call only the Nt indicates that it occurred in user-mode. We then see the [B][I]VfCheckUserHandle [/I][/B]call. If I am correct in my analysis, this indicates that a handle that was visible to user-mode was accessed in kernel-mode and does NOT have an OBJ_KERNEL_HANDLE attribute set. If a driver forgot to specify OBJ_KERNEL_HANDLE when creating a handle, it will end up creating a user-mode handle which in most cases is bad because user-mode code can now access the object than it may or may not have had access to otherwise. If we take a look at our failure bucket ID - [I]FAILURE_BUCKET_ID: X64_0xc4_f6_[COLOR=#ff0000][B]VRF[/B][/COLOR]_[COLOR=#ff0000][B]nvlddmkm+995d1[/B][/COLOR][/I] We can see that the nVidia video driver was blamed. Given all the DirectX Kernel calls leaves me curious about your RAM as well, although we'll worry about that if we have to. For now, ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try. [U][B]---------------------------------------------------------------------------------------------[/B][/U] [I][B]E1G6032E.sys - Wed May 28 19:14:51 [U][COLOR=#ff0000]2008[/COLOR][/U][/B][/I] ^^ Intel Ethernet drivers, pretty old. I'd check for an update - [url]http://downloadcenter.intel.com/Default.aspx[/url] Regards, Patrick [/QUOTE]
Insert quotes...
Verification
Post reply
Microsoft Support & Malware Removal
BSOD Crashes, Kernel Debugging
X58A-UD3R rev 2.0 Win7 BSOD i7 950 no overclock
Menu
Log in
Register
Top
