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
---------
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
---------