Recently one of my computers was performing slowly and I decided to close some programs.
When closing all Windows explorers the computer crashed with a BSOD…
After reboot this message was displayed:
Windows has recovered from an unexpected shutdown
Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1030
Additional information about the problem:
BCCode: 7f
BCP1: 0000000000000008
BCP2: 0000000080050031
BCP3: 00000000000006F8
BCP4: FFFFF9600025C28C
OS Version: 6_1_7601
Service Pack: 1_0
Product: 768_1
A similar message was logged in Event Viewer:
Log Name: System
Source: Microsoft-Windows-WER-SystemErrorReporting
Event ID: 1001
Task Category: None
Level: Error
Keywords: Classic
Description:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007f (0x0000000000000008, 0x0000000080050031, 0x00000000000006f8, 0xfffff9600025c28c). A dump was saved in: C:\Windows\MEMORY.DMP.
Decided to examine this further, so started WinDbg (x64) and opened:
C:\Windows\Memory.dmp
This message was displayed:
BugCheck 7F, {8, 80050031, 6f8, fffff9600025c28c}
Checked for more details with:
!analyze -v
Part of the result:
*****************************************************************
* *
* Bugcheck Analysis *
* *
*****************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff9600025c28c
Decided to search online for: UNEXPECTED_KERNEL_MODE_TRAP (7f) exception double fault
And found this article: Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP
It mentioned that a common cause for this error was kernel stack overflow.
So I checked the stack usage with:
!stackusage
The result was:
Stack Usage By Function
===================================================================
Size Count Module
0x00001500 14 win32k!xxxDesktopWndProcWorker
0x00000DD0 13 win32k!xxxInterSendMsgEx
0x00000D20 14 win32k!xxxReceiveMessage
0x000009C0 13 win32k!xxxRealSleepThread
0x000008F0 13 win32k!xxxSendMessageTimeout
0x000004E0 13 win32k!xxxBeginPaint
0x00000410 13 win32k!xxxSendNCPaint
0x00000400 2 win32k!RGNOBJAPI::bSubtractComplex
0x00000380 1 win32k!CalcVisRgnWorker
0x000002A0 14 win32k!xxxDesktopWndProc
0x00000270 13 win32k!xxxSleepThread
0x000000E0 1 win32k!xxxRealInternalGetMessage
0x00000090 1 win32k!xxxHandleDesktopMessages
0x00000090 1 win32k!GetDCEx
0x00000080 1 win32k!xxxDesktopThread
0x00000080 1 win32k!RGNOBJAPI::bSubtract
0x00000060 1 win32k!xxxBeginPaint
0x00000050 1 win32k!GreSubtractRgnRectList
0x00000040 1 win32k!xxxInternalGetMessage
0x00000030 1 win32k!xxxCreateSystemThreads
0x00000030 1 win32k!CalcVisRgn
0x00000030 1 win32k!NtUserCallNoParam
Total Size: 0x00005CA0
Stack Usage By Module
===================================================================
Size Count Module
0x00005CA0 134 win32k
Total Size: 0x00005CA0
Noticed that 0x5CA0 = 23712 bytes is very close to the 24K kernel stack limit for 64-bit Windows.
The most likely cause for the BSOD was indeed kernel stack overflow.
Examined the call stack with:
kf
Part of the result:
# Memory Child-SP RetAddr Call Site
00 fffff800`0449ed28 fffff800`030889e9 nt!KeBugCheckEx
01 8 fffff800`0449ed30 fffff800`03086eb2 nt!KeSynchronizeExecution+0x3d39
02 140 fffff800`0449ee70 fffff960`0025c28c nt!KeSynchronizeExecution+0x2202
03 20f4110 fffff880`06592f80 fffff960`0025c1c1 win32k!RGNOBJAPI::bSubtractComplex+0x44
04 400 fffff880`06593380 fffff960`001d3379 win32k!RGNOBJAPI::bSubtract+0x871
05 80 fffff880`06593400 fffff960`0014d7c4 win32k!GreSubtractRgnRectList+0x49
06 50 fffff880`06593450 fffff960`000c5c47 win32k!CalcVisRgnWorker+0x314
07 380 fffff880`065937d0 fffff960`000d23be win32k!CalcVisRgn+0x97
08 30 fffff880`06593800 fffff960`00056cf6 win32k!GetDCEx+0x50e
09 90 fffff880`06593890 fffff960`0009ede7 win32k!xxxBeginPaint+0x192
0a 60 fffff880`065938f0 fffff960`0009ead5 win32k!xxxDesktopWndProcWorker+0x2f7
0b 180 fffff880`06593a70 fffff960`00094013 win32k!xxxDesktopWndProc+0x55
0c 30 fffff880`06593aa0 fffff960`000def3f win32k!xxxReceiveMessage+0x6cb
Noticed the very large stack frame difference at:
win32k!RGNOBJAPI::bSubtractComplex+0x44
Examined details about win32k.sys with:
lmDvm win32k
Part of the result:
Image path: \SystemRoot\System32\win32k.sys
Image name: win32k.sys
Timestamp: Mon Sep 12 22:37:06 2016 (57D711F2)
CheckSum: 00314AE8
ImageSize: 00326000
File version: 6.1.7601.23545
Product version: 6.1.7601.23545
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: win32k.sys
OriginalFilename: win32k.sys
ProductVersion: 6.1.7601.23545
FileVersion: 6.1.7601.23545 (win7sp1_ldr.160912-1137)
FileDescription: Multi-User Win32 Driver
LegalCopyright: © Microsoft Corporation. All rights reserved.
Noticed that win32k.sys had been updated recently.
Knowing that win32k.sys interacts with the graphics driver, I decided to update this to the latest version.
