MiniDump Analysis

My first time using WinDbg. Seeing as how the Dell Diagnostics went ape when testing the RAM failing on a bunch of the tests, I assume the two are related but any help would be greatly appreciated.

The BSOD came mostly after waking up from StandBy.

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini021610-02.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 XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.090804-1435
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Tue Feb 16 14:03:10.609 2010 (GMT-5)
System Uptime: 0 days 2:05:54.392
Loading Kernel Symbols
...............................................................
................................................................
..........................
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 805bc207, b3f19c7c, 0}

Probably pool corruption caused by Tag: CcPL

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 805bc207, The address that the exception occurred at
Arg3: b3f19c7c, Trap Frame
Arg4: 00000000

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
nt!ObpCloseHandleTableEntry+13
805bc207 83b9a800000000 cmp dword ptr [ecx+0A8h],0

TRAP_FRAME: b3f19c7c -- (.trap 0xffffffffb3f19c7c)
ErrCode = 00000000
eax=e3f8dbc0 ebx=8a548b08 ecx=00000000 edx=886f8ef9 esi=886f8ef8 edi=e3f8dbc0
eip=805bc207 esp=b3f19cf0 ebp=b3f19cfc iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!ObpCloseHandleTableEntry+0x13:
805bc207 83b9a800000000 cmp dword ptr [ecx+0A8h],0 ds:0023:000000a8=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: svchost.exe

CORRUPTING_POOL_ADDRESS: 886f8ee8

CORRUPTING_POOL_TAG: CcPL

LAST_CONTROL_TRANSFER: from 805bc3df to 805bc207

STACK_TEXT:
b3f19cfc 805bc3df e3ddd450 e3f8dbc0 000005e0 nt!ObpCloseHandleTableEntry+0x13
b3f19d44 805bc517 000005e0 00000001 00000000 nt!ObpCloseHandle+0x87
b3f19d58 8054162c 000005e0 00addeb0 7c90e514 nt!NtClose+0x1d
b3f19d58 7c90e514 000005e0 00addeb0 7c90e514 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
00addeb0 00000000 00000000 00000000 00000000 0x7c90e514


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ObpCloseHandleTableEntry+13
805bc207 83b9a800000000 cmp dword ptr [ecx+0A8h],0

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!ObpCloseHandleTableEntry+13

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a784394

FAILURE_BUCKET_ID: CORRUPTING_POOLTAG_CcPL

BUCKET_ID: CORRUPTING_POOLTAG_CcPL

Followup: MachineOwner
---------

1: kd> lmvm nt
start end module name
804d7000 806e4000 nt # (pdb symbols) c:\symbols\ntkrpamp.pdb\D8743252F83B4F59985D6E19F33BFCAF1\ntkrpamp.pdb
Loaded symbol image file: ntkrpamp.exe
Mapped memory image file: c:\symbols\ntkrpamp.exe\4A78439420d000\ntkrpamp.exe
Image path: ntkrpamp.exe
Image name: ntkrpamp.exe
Timestamp: Tue Aug 04 10:20:04 2009 (4A784394)
CheckSum: 001F365F
ImageSize: 0020D000
File version: 5.1.2600.5857
Product version: 5.1.2600.5857
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0804.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft(R) Windows(R) Operating System
InternalName: ntkrpamp.exe
OriginalFilename: ntkrpamp.exe
ProductVersion: 5.1.2600.5857
FileVersion: 5.1.2600.5857 (xpsp_sp3_gdr.090804-1435)
FileDescription: NT Kernel & System
LegalCopyright: (C) Microsoft Corporation. All rights reserved.
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 805bc207, The address that the exception occurred at
Arg3: b3f19c7c, Trap Frame
Arg4: 00000000

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
nt!ObpCloseHandleTableEntry+13
805bc207 83b9a800000000 cmp dword ptr [ecx+0A8h],0

TRAP_FRAME: b3f19c7c -- (.trap 0xffffffffb3f19c7c)
ErrCode = 00000000
eax=e3f8dbc0 ebx=8a548b08 ecx=00000000 edx=886f8ef9 esi=886f8ef8 edi=e3f8dbc0
eip=805bc207 esp=b3f19cf0 ebp=b3f19cfc iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!ObpCloseHandleTableEntry+0x13:
805bc207 83b9a800000000 cmp dword ptr [ecx+0A8h],0 ds:0023:000000a8=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: svchost.exe

CORRUPTING_POOL_ADDRESS: 886f8ee8

CORRUPTING_POOL_TAG: CcPL

LAST_CONTROL_TRANSFER: from 805bc3df to 805bc207

STACK_TEXT:
b3f19cfc 805bc3df e3ddd450 e3f8dbc0 000005e0 nt!ObpCloseHandleTableEntry+0x13
b3f19d44 805bc517 000005e0 00000001 00000000 nt!ObpCloseHandle+0x87
b3f19d58 8054162c 000005e0 00addeb0 7c90e514 nt!NtClose+0x1d
b3f19d58 7c90e514 000005e0 00addeb0 7c90e514 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
00addeb0 00000000 00000000 00000000 00000000 0x7c90e514


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ObpCloseHandleTableEntry+13
805bc207 83b9a800000000 cmp dword ptr [ecx+0A8h],0

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!ObpCloseHandleTableEntry+13

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a784394

FAILURE_BUCKET_ID: CORRUPTING_POOLTAG_CcPL

BUCKET_ID: CORRUPTING_POOLTAG_CcPL

Followup: MachineOwner