New
#1
Rolled out Office 2010 and got BSOD BAD_POOL_HEADER
We rolled out Office 2010 yesterday to some of our users through SCCM and when they started using the program this morning they got a BSOD.
Here is the WinDbg DMP output:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\debugger_x86\dmps\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: srv*
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff800`02a05000 PsLoadedModuleList = 0xfffff800`02c48670
Debug session time: Wed Jun 19 07:10:17.391 2013 (UTC - 4:00)
System Uptime: 0 days 15:30:40.118
Loading Kernel Symbols
...............................................................
................................................................
............................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 000007ff`fffdf018). Type ".hh dbgerr001" for details
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 19, {21, fffff900c0b2f000, 1060, 0}
Page 7f543 not present in the dump file. Type ".hh dbgerr004" for details
Page 96b6d not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : win32k.sys ( win32k!EngFreeMem+21 )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000021, the data following the pool block being freed is corrupt. Typically this means the consumer (call stack ) has overrun the block.
Arg2: fffff900c0b2f000, The pool pointer being freed.
Arg3: 0000000000001060, The number of bytes allocated for the pool block.
Arg4: 0000000000000000, The corrupted value found following the pool block.
Debugging Details:
------------------
BUGCHECK_STR: 0x19_21
POOL_ADDRESS: fffff900c0b2f000 Paged session pool
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80002bad9b2 to fffff80002a7ac00
STACK_TEXT:
fffff880`0750ce98 fffff800`02bad9b2 : 00000000`00000019 00000000`00000021 fffff900`c0b2f000 00000000`00001060 : nt!KeBugCheckEx
fffff880`0750cea0 fffff960`00039415 : 00000000`011d1c8a 00000000`00000000 fffff880`64667454 fffff880`00000000 : nt!ExDeferredFreePool+0xfaa
fffff880`0750cf50 fffff960`00041df4 : 00000000`011d1c8a fffff880`0750d000 00000000`00000509 00000000`011d0b08 : win32k!EngFreeMem+0x21
fffff880`0750cf80 fffff960`0003915b : fffff900`c0fc32d0 00000000`00000001 00000000`00000001 00000000`00000000 : win32k!bLoadGlyphSet+0x104
fffff880`0750cfb0 fffff960`000392fa : fffff900`c0fc32d0 fffff900`00000001 fffff900`c0fc32d0 fffff960`001ac344 : win32k!bReloadGlyphSet+0x24b
fffff880`0750d670 fffff960`00039252 : 00000000`00000000 fffff900`c0fc32d0 fffff900`00000001 fffff900`c0d7d264 : win32k!ttfdQueryFontTree+0x66
fffff880`0750d6c0 fffff960`000860d7 : fffff960`000391f8 fffff900`c0fc3610 00000000`00000001 00000000`00000000 : win32k!ttfdSemQueryFontTree+0x5a
fffff880`0750d700 fffff960`00085f83 : fffff880`0750d810 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!PDEVOBJ::QueryFontTree+0x63
fffff880`0750d780 fffff960`0004003e : fffff900`c008a010 00000000`00000000 00000000`00000002 00000000`00000000 : win32k!PFEOBJ:fdg+0xa3
fffff880`0750d7e0 fffff960`0009a750 : fffff900`c0d7d150 fffff880`0750da70 fffff880`0750d970 fffff880`0750da40 : win32k!RFONTOBJ::bRealizeFont+0x46
fffff880`0750d900 fffff960`0003c020 : 00000000`10018000 fffff900`00000000 fffff900`00000000 fffff960`00000002 : win32k!RFONTOBJ::bInit+0x548
fffff880`0750da20 fffff960`00046fef : 00000000`00000000 00000000`75e50180 00000000`00000000 00000000`00000000 : win32k!GreGetTextMetricsW+0x4c
fffff880`0750da60 fffff800`02a79e93 : fffffa80`04c76640 fffff880`0750db60 00000000`00000000 fffff900`c01a7010 : win32k!NtGdiGetTextMetricsW+0x1f
fffff880`0750dae0 00000000`74e82e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0009e738 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74e82e09
STACK_COMMAND: kb
FOLLOWUP_IP:
win32k!EngFreeMem+21
fffff960`00039415 4883c420 add rsp,20h
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: win32k!EngFreeMem+21
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: win32k
IMAGE_NAME: win32k.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5164dccb
FAILURE_BUCKET_ID: X64_0x19_21_win32k!EngFreeMem+21
BUCKET_ID: X64_0x19_21_win32k!EngFreeMem+21
Followup: MachineOwner
---------
Can anyone help me determine what actually caused the error? I ran memtest on a couple of the machines and it came back clean.
Thanks,
Jason