Jump to content

Random Blue Screen Error Message

adrian2055

By adrian2055
in Windows Vista

 Share

Recommended Posts


cluberti

cluberti

Posted
Posted

Uh oh - dump is corrupt:

**************************************************************************
THIS DUMP FILE IS PARTIALLY CORRUPT.
KdDebuggerDataBlock is not present or unreadable.
**************************************************************************

Link to comment
Share on other sites
adrian2055

adrian2055

Posted
  • Author
Posted

Dang! Sorry about that. I had one more since then. I think It just added to the other one because the memory.dmp file was modified reccently, but it was creadted over 9 hours ago. Would that one work? I'm tempted to format the drive are re-install everything. Would that help?

Link to comment
Share on other sites
cluberti

cluberti

Posted
Posted

Dang! Sorry about that. I had one more since then. I think It just added to the other one because the memory.dmp file was modified reccently, but it was creadted over 9 hours ago. Would that one work? I'm tempted to format the drive are re-install everything. Would that help?

That depends - if you load the machine with the same software, maybe, but maybe not. And if it is a hardware problem, then no for sure.

I'd upload the latest one from just awhile ago - that will be fine.

Link to comment
Share on other sites
cluberti

cluberti

Posted
Posted

Well, this seems pretty random to me:

// Trap frame showing the reason for the bugcheck:
1: kd> .trap 0xffffffff980669a0
ErrCode = 00000002
eax=fe484008 ebx=00000001 ecx=fe4843d4 edx=fe4840f0 esi=00732691 edi=fe484070
eip=92ccad63 esp=98066a14 ebp=98066cd4 iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010206
win32k!xxxUserProcessCallout+0xe9:
92ccad63 007409ff        add     byte ptr [ecx+ecx-1],dh    ds:0023:fc9087a7=??

// The thread is in IE, trying to write to GDI via win32k.sys:
1: kd> !thread
THREAD 866f97e8  Cid 0b34.0b5c  Teb: 7ffd9000 Win32Thread: fe51c008 RUNNING on processor 1
Not impersonating
DeviceMap                 978ae870
Owning Process            866f0860       Image:         iexplore.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      26616          Ticks: 0
Context Switch Count      18648             
UserTime                  00:00:19.875
KernelTime                00:00:09.656
Win32 Start Address iertutil!CIsoScope::RegisterThread (0x7681407f)
Stack Init 98066fe0 Current 98066ce0 Base 98067000 Limit 98064000 Call 42c
Priority 11 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
ChildEBP RetAddr  Args to Child              
98066988 81a56dd4 00000001 fc9087a7 00000000 nt!MmAccessFault+0x10a
98066988 92ccad63 00000001 fc9087a7 00000000 nt!KiTrap0E+0xdc (FPO: [0,0] TrapFrame @ 980669a0)
98066cd4 92c7a9bf a1010979 00000199 0000013d win32k!xxxUserProcessCallout+0xe9 (FPO: [2,3,4])
98066d30 81a53c7a a1010979 00000199 0000013d win32k!NtGdiLineTo+0x64 (FPO: [3,17,4])
98066d30 77a25e74 a1010979 00000199 0000013d nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 98066d44)
029e8828 7797c6ae 7797c696 a1010979 00000199 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
029e882c 7797c696 a1010979 00000199 0000013d GDI32!NtGdiLineTo+0xc (FPO: [3,0,0])
029e884c 6cf62a8f a1010979 00000199 0000013d GDI32!LineTo+0x92 (FPO: [3,0,4])
029e887c 6cf6cb1d 00000000 029e88f0 029e8bd0 mshtml!XHDC::LineTo+0x5e
029e88d4 6cf64b33 00000000 0a6ca610 00000000 mshtml!DrawSimpleBorder+0x298
029e8bb0 6cf648ab 029ed3d0 029ed3c0 0a6ca610 mshtml!DrawBorder+0x2055
029e8bf4 6cedd21d 029ed360 029ed3c0 029e8c70 mshtml!DrawBorder+0x38
029e8cd8 6cf6291c 029e8d18 029e8d28 0a6ca610 mshtml!CDisplayBox::DrawClientBorder+0x1e1
029e8d38 6ce286e4 003e89d0 029e8e64 0aad3058 mshtml!CDispNode::DrawBorder+0xed
029e8f04 6ce28e7f 003e89d0 09a6b078 00000007 mshtml!CDispContainer::DrawSelf+0x15f
029e9050 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x217
029e9078 6cedc7fd 003e89d0 029e9308 003e89d0 mshtml!CDispContainer::DrawChildren+0x56
029e9128 6ce294c8 09a6b024 003e89d0 029e91d0 mshtml!CDispContainer::DrawContentAdvanced+0x9b
029e92fc 6ce28e7f 003e89d0 09a6b024 00000007 mshtml!CDispContainer::DrawSelf+0x2b4
029e9448 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x217
029e9470 6cede25e 003e89d0 029e95c8 00040000 mshtml!CDispContainer::DrawChildren+0x56
029e95bc 6cede0cf 003e89d0 0a9da258 00000007 mshtml!CDispContainer::DrawChildrenInActiveLayer+0x7e
029e9708 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x207
029e9730 6cede25e 003e89d0 029e9888 00040000 mshtml!CDispContainer::DrawChildren+0x56
029e987c 6cede0cf 003e89d0 0aa4ef70 00000007 mshtml!CDispContainer::DrawChildrenInActiveLayer+0x7e
029e99c8 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x207
029e99f0 6cedc7fd 003e89d0 029e9c80 003e89d0 mshtml!CDispContainer::DrawChildren+0x56
029e9aa0 6ce294c8 0acd03b4 003e89d0 029e9b48 mshtml!CDispContainer::DrawContentAdvanced+0x9b
029e9c74 6ce28e7f 003e89d0 0acd03b4 00000007 mshtml!CDispContainer::DrawSelf+0x2b4
029e9dc0 6cede42a 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x217
029e9dec 6ce28e7f 003e89d0 00000000 00000007 mshtml!CDispProxyNode::DrawSelf+0x7b
029e9f38 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x217
029e9f60 6cede27e 003e89d0 029ea1f0 003e89d0 mshtml!CDispContainer::DrawChildren+0x56
029ea010 6ce294c8 0a7e6000 003e89d0 029ea0b8 mshtml!CDispContainer::DrawContentAdvanced+0xb5
029ea1e4 6ce28e7f 003e89d0 0a883d48 00000007 mshtml!CDispContainer::DrawSelf+0x2b4
029ea330 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x217
029ea358 6ce2952e 003e89d0 029ea528 00000000 mshtml!CDispContainer::DrawChildren+0x56
029ea51c 6ce28e7f 003e89d0 0a7bef28 00000007 mshtml!CDispContainer::DrawSelf+0x28a
029ea668 6ce2959e 00000000 003e89d0 00000000 mshtml!CDispNode::Draw+0x217
029ea690 6ce2952e 003e89d0 029ea860 00000000 mshtml!CDispContainer::DrawChildren+0x56

// Disassembly:
1: kd> u 92ccad63 
win32k!xxxUserProcessCallout+0xe9:
92ccad63 007409ff        add     byte ptr [ecx+ecx-1],dh
92ccad67 7604            jbe     win32k!xxxUserProcessCallout+0xf3 (92ccad6d)
92ccad69 57              push    edi
92ccad6a e8216bffff      call    win32k!DestroyCacheDC (92cc1890)
92ccad6f 3b37            cmp     esi,dword ptr [edi]
92ccad71 7502            jne     win32k!xxxUserProcessCallout+0xfb (92ccad75)
92ccad73 8bfe            mov     edi,esi
92ccad75 8b37            mov     esi,dword ptr [edi]

// Looking at registers to get the PTE:
1: kd> r
Last set context:
eax=fe484008 ebx=00000001 ecx=fe4843d4 edx=fe4840f0 esi=00732691 edi=fe484070
eip=92ccad63 esp=98066a14 ebp=98066cd4 iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010206
win32k!xxxUserProcessCallout+0xe9:
92ccad63 007409ff        add     byte ptr [ecx+ecx-1],dh    ds:0023:fc9087a7=??

// The PTE contains nothing - this is bad:
1: kd> !pte fc9087a7
               VA fc9087a7
PDE at 00000000C0603F20    PTE at 00000000C07E4840
contains 0000000000000000

// The pool allocation behind this is corrupt, either because pool is corrupt or the pointer is wrong:
1: kd> !pool fc9087a7
Pool page fc9087a7 region is Unknown
fc908000 is not a valid large pool allocation, checking large session pool...
fc908000 is freed (or corrupt) pool
Bad allocation size @fc908000, too large

1: kd> !poolval fc908000
Pool page fc908000 region is Unknown

Validating Pool headers for pool page: fc908000

Pool page [ fc908000 ] is __inVALID.

Honestly, at this point, your system memory is indeed suspect - either you have the buggiest install of Vista I've ever heard of (not likely), or you've got bad hardware underneath (these two at the least are in no way related, at all).

Link to comment
Share on other sites
adrian2055

adrian2055

Posted
  • Author
Posted

I had a feeling you were gonna say that. The vista install was a fresh install from my retail dvd. Maybe I had some issues when I had to do a recovery on the drive. just formatted the drive and re-installed vista. I'll see if that helps. If not, then I'll know it's the memory. Which stick should I replace? The old one or the new one?

Link to comment
Share on other sites
cluberti

cluberti

Posted
Posted

I'd remove the new one and test the old one with memtest86+, as many passes as you can stand. Then I'd do the same with the old one. Assuming you get to a point where both pass, I'd run without the old one for awhile and see what happens.

Link to comment
Share on other sites
CoffeeFiend

CoffeeFiend

Posted
Posted

Like he said. The other thing is, chances are both sticks are good, but that your BIOS has issues with the 2 sticks being different (different SPD info, etc), and picks values that one of them doesn't like. I'd set the voltages and timings by hand in the BIOS to something conservative which should work for both (I'm assuming it's a non-ghetto BIOS where you actually can set those things). It's worth a try.

Link to comment
Share on other sites
dencorso

dencorso

Posted
Posted

Before you take them out, use cpu-z to read the actual ram timings, as they are, and the SPD info&tables for each stick and report them here (the info under the "Memory" and "SPD" tabs, in the "SPD" select each ram stick in the box, to see its info). It may prove Coffee's point.

Link to comment
Share on other sites
dencorso

dencorso

Posted
Posted

Both sticks in principle support the selfsame timings. But I'd like to see whether your system behaves better after some RAM underclocking... Would you please set the FSB:SDRAM ratio to 3:4, just for testing purposes? I bet you'll hardly notice the memory slowdown caused by it in actual day-to-day use, except when using RAM performance benchmarks... and it may stabilize your machine (then again, it may not)... and the only way to find out is by trying it.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...