BSOD BAD_POOL_HEADER 0x19

[Aleatoire]

Hi there, I helped a friend of mine put together his first build a couple of weeks ago. Unfortunately he's started getting BSOD. I'm new to analysing dump files so I'd appreciate a bit of help. I understand that the error occurred in win32.sys, but I'm not sure why. When the dump file says "PROCESS_NAME: chrome.exe", does this mean that Chrome caused to BSOD?
It would be great if you could give me some help, and if it's not too much trouble, let me know how you came to the conclusion that you came to; I'm interested in learning. Thanks.

Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [F:\Documents\Drop Stuff Here!\090814-18049-01 - Copy.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c5a000 PsLoadedModuleList = 0xfffff800`02e97e50
Debug session time: Mon Sep 8 14:08:21.360 2014 (UTC + 12:00)
System Uptime: 12 days 21:03:26.877
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
..................................
Loading User Symbols
Loading unloaded module list
...................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 19, {21, fffff900c2a45000, 2030, 200053000}

Probably caused by : win32k.sys ( win32k!FreeTmpBuffer+1e )

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

2: 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: fffff900c2a45000, The pool pointer being freed.
Arg3: 0000000000002030, The number of bytes allocated for the pool block.
Arg4: 0000000200053000, The corrupted value found following the pool block.

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


BUGCHECK_STR: 0x19_21

POOL_ADDRESS: GetPointerFromAddress: unable to read from fffff80002f020e0
GetUlongFromAddress: unable to read from fffff80002f02198
fffff900c2a45000

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: chrome.exe

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from fffff80002dfd3cd to fffff80002ccbf00

STACK_TEXT:
fffff880`0badb9c8 fffff800`02dfd3cd : 00000000`00000019 00000000`00000021 fffff900`c2a45000 00000000`00002030 : nt!KeBugCheckEx
fffff880`0badb9d0 fffff960`0011619e : 00000000`002a9548 00000000`002a9548 00000000`706d5447 00000000`00000001 : nt!ExFreePool+0xa6a
fffff880`0badba80 fffff960`00287b34 : fffff900`c2a45020 fffff880`0badbc60 00000000`7078616d fffff900`c4571ca0 : win32k!FreeTmpBuffer+0x1e
fffff880`0badbab0 fffff800`02ccb153 : 00000000`0a01320e 00000000`000f0047 00000000`00000182 00000000`002a9548 : win32k!NtGdiGetGlyphOutline+0x180
fffff880`0badbb70 00000000`74a11daa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`000fdd48 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74a11daa


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!FreeTmpBuffer+1e
fffff960`0011619e 4883c428 add rsp,28h

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: win32k!FreeTmpBuffer+1e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc5e0

IMAGE_VERSION: 6.1.7600.16385

FAILURE_BUCKET_ID: X64_0x19_21_win32k!FreeTmpBuffer+1e

BUCKET_ID: X64_0x19_21_win32k!FreeTmpBuffer+1e

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0x19_21_win32k!freetmpbuffer+1e

FAILURE_ID_HASH: {8c089189-2d52-f4ec-175f-e6bb8577e957}

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

 

[Shaun o]

When you get a bad pool header error of any kind it can relate to two or three things.

Every driver is routed through the core files of windows system and kernal.
If a call from a driver is made to the cpu to access a memory location in ram.
It is given the start point of the memory location, the length to address, and its end point.

From the driver, through windows the memory location is called from the cpu to the memory, and back again.
Each driver has a set Irq channel used on the computer paired with, or associated with a bit of hard ware.
If you look at the resources tab you will see the memory address range allocated for use with a driver and the hardware it talks to, the irq number, and the Io range.

The problem occurs when you have two or more devices wishing to share a same Irq number and memory address range.
So the message means the data requested at the memory address range cannot be accessed as it is in use by another bit of hardware or reserved..

In a sense you have a driver with a bit of hardware, trying to compete with another driver and a bit of hardware wanting access or reservation of the same pool header or set memory address range to read and written to.

The quick fix some times can be to enter the bios and disable external Io or ports that are not used on the system.
Examples are com ports, serial ports. this will free up Irq numbers allowing devices to have there own Irq number to talk to the cpu and system memory.

Your other option is to set the plug and play option in the bios to manual and see if it resolves the problem.
Or to relocate any hardware devices fitted to Pci-e slots in a set order, or any based Pci slots to any other extra slots provided by the board.

The last option is to check that any drivers used are up to date used with any hardware in the system.

 

[Aleatoire]

I understand, thanks for your help and the explanation. I'll tell him to try the things that you've suggested.
I installed some USB 3.0 drivers from the motherboard disk (one of two options) which turned out not to work. By that point I no longer had access to the computer and told my friend to install the other set of drivers from the disk. He said that that got things working properly. I'm not sure if he ever uninstalled the first set of drivers. Could this double up of USB 3.0 drivers be the cause of the issue or is one driver for the back ports and the other driver for the front ports?

 

[johnbl]

you have a very old version of window with out the service pack or hotfixes installed. You should do a windows update. Also, various old USB drivers do tend to have bugs that cause them to rampage thru memory and corrupt other drivers data. This causes the other drivers to bugcheck. the bugchecks tend to be different each time you boot windows because windows will load the drivers in slightly different orders on each boot. The bad driver tends to corrupt the data of the driver that is using the memory area next to its driver.

so with a usb driver you generally want to update the BIOS, update the CPU chipset driver
(google intel cpu chipset drivers if you have a intel CPU)
some motherboards will also have a 3rd party USB 3.0 chipset driver that you might have to update
but you will have to look up your motherboard, find the chipset name and google for the driver.

Note: for usb problem you might want to get a copy of usbview.exe
it is provided free by microsoft in the windows sdk http://msdn.microsoft.com/en-US/windows/desktop/bg162891 you just want the standalone tools only, and it just dumps them onto your hard drive and you have to locate the file and run it.

you can also use windows device manager but you have to turn on hidden devices because thedrivers can still be loaded even if the device is unplugged. You make it display the hidden devices then delete the old drivers.

the usbview.exe is useful, it will show all your ports and any that have a problem.
(i have one machine with one broken port that I could never get to work correctly, I ended up putting tape over the port so I would not bugcheck the machine)