Windows 7 Forums
Welcome to Windows 7 Forums. Our forum is dedicated to helping you find support and solutions for any problems regarding your Windows 7 PC be it Dell, HP, Acer, Asus or a custom build. We also provide an extensive Windows 7 tutorial section that covers a wide range of tips and tricks.

Windows 7: BSOD double fault, win32k.sys using excessive kernel stack space

26 Oct 2018   #1
regular old dan

Windows 7 Professional
BSOD double fault, win32k.sys using excessive kernel stack space

Hi all, I unfortunately can't run any 3rd party software or upload raw data from the PCs in question, but we're seeing a large number of BSODs at work and all have a similar signature to this - a double fault when the kernel thread looks like it overruns the 24kb available, and almost all that is being used by win32k.sys apparently recursing. Why on earth win32k seems to be going through the same functions over and over, I have no idea, but here it's using 23088 bytes of kernel stack.

I realize there's probably no way anyone can tell why win32k is doing this since we don't have the code/symbols to see the messages it's sending, I was more curious as to whether anyone's seen something like this before. I realize the sk.sys and mcafee drivers are in the trace, however they're using a tiny amount of stack space compared to win32k. I have other examples where the call stack is win32k -> ProcessMouseInput -> Intel gfx driver -> double fault, again with win32k using 16-20 kbytes of kernel stack.

This is the output of windbg kf, !analyze -v, !stackusage. I can run any other commands you'd like as long as the output can be sanitized, i.e. doesn't show raw memory values.

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

Loading Dump File [C:\dumps\10_24_Dumps\123-WS-DD36K2W.dmp]
Kernel Complete Dump File: Full 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.24231.amd64fre.win7sp1_ldr.180810-0600
Machine Name:
Kernel base = 0xfffff800`0344f000 PsLoadedModuleList = 0xfffff800`03689c90
Debug session time: Wed Oct 24 10:54:07.022 2018 (UTC - 5:00)
System Uptime: 0 days 16:22:04.499
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050031, 406f8, fffff88004afe4ec}

*** ERROR: Module load completed but symbols could not be loaded for atikmdag.sys
*** ERROR: Module load completed but symbols could not be loaded for atikmpag.sys
*** ERROR: Module load completed but symbols could not be loaded for mfeaack.sys
*** ERROR: Module load completed but symbols could not be loaded for mfehidk.sys
*** ERROR: Module load completed but symbols could not be loaded for sk.sys
Probably caused by : win32k.sys

Followup:     MachineOwner

Processing initial command 'kF; !analyze -v; !stackusage'
0: kd> kF; !analyze -v; !stackusage
#   Memory  Child-SP          RetAddr           Call Site
00           fffff800`04b49d08 fffff800`034f0d69 nt!KeBugCheckEx
01         8 fffff800`04b49d10 fffff800`034ed84b nt!KiBugCheckDispatch+0x69
02       140 fffff800`04b49e50 fffff880`04afe4ec nt!KiDoubleFaultAbort+0x28b
03  fd8861a0 fffff880`023cfff0 fffff880`04b03f24 atikmdag+0xd64ec
04        80 fffff880`023d0070 fffff880`04b0432e atikmdag+0xdbf24
05        90 fffff880`023d0100 fffff880`04b0a2d6 atikmdag+0xdc32e
06        90 fffff880`023d0190 fffff880`04afcd98 atikmdag+0xe22d6
07        80 fffff880`023d0210 fffff880`04a70cc7 atikmdag+0xd4d98
08        30 fffff880`023d0240 fffff880`041b64a9 atikmdag+0x48cc7
09        30 fffff880`023d0270 fffff800`034e3608 atikmpag+0x54a9
0a        30 fffff880`023d02a0 fffff800`03488788 nt!KiInterruptDispatch+0xb8
0b       190 fffff880`023d0430 fffff880`05e2c303 nt!KeAcquireSpinLockRaiseToDpc+0x28
0c        50 fffff880`023d0480 fffff880`05e53be7 mfeaack+0x2c303
0d        30 fffff880`023d04b0 fffff880`05e53d78 mfeaack+0x53be7
0e        30 fffff880`023d04e0 fffff880`05e54b36 mfeaack+0x53d78
0f        40 fffff880`023d0520 fffff880`05e563c1 mfeaack+0x54b36
10       240 fffff880`023d0760 fffff880`05e4ee21 mfeaack+0x563c1
11       140 fffff880`023d08a0 fffff880`05e4f2bf mfeaack+0x4ee21
12        b0 fffff880`023d0950 fffff880`05e34785 mfeaack+0x4f2bf
13        70 fffff880`023d09c0 fffff880`05e3587c mfeaack+0x34785
14        70 fffff880`023d0a30 fffff880`05e35de4 mfeaack+0x3587c
15        50 fffff880`023d0a80 fffff880`05e1d58d mfeaack+0x35de4
16        e0 fffff880`023d0b60 fffff880`05e25a99 mfeaack+0x1d58d
17        80 fffff880`023d0be0 fffff880`01678939 mfeaack+0x25a99
18       190 fffff880`023d0d70 fffff880`0167978e mfehidk+0x48939
19        30 fffff880`023d0da0 fffff800`0382be76 mfehidk+0x4978e
1a        30 fffff880`023d0dd0 fffff800`0382c37f nt!ObpCallPreOperationCallbacks+0x196
1b        80 fffff880`023d0e50 fffff800`037c7a3f nt!ObpPreInterceptHandleCreate+0xaf
1c        80 fffff880`023d0ed0 fffff800`0374b801 nt! ?? ::NNGAKEGL::`string'+0x1b81f
1d       110 fffff880`023d0fe0 fffff800`0375e000 nt!ObOpenObjectByPointerWithTag+0x109
1e       220 fffff880`023d1200 fffff880`00f5bfd3 nt!ObOpenObjectByPointer+0x30
1f        50 fffff880`023d1250 fffff880`00f5c1b6 sk+0x68fd3
20        80 fffff880`023d12d0 fffff880`00f53931 sk+0x691b6
21        30 fffff880`023d1300 fffff880`00f537d2 sk+0x60931
22        70 fffff880`023d1370 fffff880`00f529f4 sk+0x607d2
23       130 fffff880`023d14a0 fffff880`00f249c0 sk+0x5f9f4
24       120 fffff880`023d15c0 fffff880`00f23f74 sk+0x319c0
25        e0 fffff880`023d16a0 fffff880`00ef5a1a sk+0x30f74
26       160 fffff880`023d1800 fffff880`00f30ae7 sk+0x2a1a
27        60 fffff880`023d1860 fffff880`00f31b95 sk+0x3dae7
28        d0 fffff880`023d1930 fffff880`00f51511 sk+0x3eb95
29        40 fffff880`023d1970 fffff800`0373c928 sk+0x5e511
2a        30 fffff880`023d19a0 fffff800`034f09d3 nt!NtReadFile+0x718
2b       130 fffff880`023d1ad0 fffff800`034e61b0 nt!KiSystemServiceCopyEnd+0x13
2c       208 fffff880`023d1cd8 fffff960`001cb943 nt!KiServiceLinkage
2d         8 fffff880`023d1ce0 fffff960`0016d0b0 win32k!StartDeviceRead+0x1df
2e        60 fffff880`023d1d40 fffff800`0347c5bd win32k!InputApc+0x84
2f        30 fffff880`023d1d70 fffff800`0348813d nt!KiDeliverApc+0x21d
30        80 fffff880`023d1df0 fffff800`0349ae42 nt!KiCommitThreadWait+0x3dd
31        90 fffff880`023d1e80 fffff960`0013ef77 nt!KeWaitForMultipleObjects+0x272
32       2c0 fffff880`023d2140 fffff960`0013f039 win32k!xxxRealSleepThread+0x2ab
33        c0 fffff880`023d2200 fffff960`000f52d3 win32k!xxxSleepThread+0x59
34        30 fffff880`023d2230 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
35       110 fffff880`023d2340 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
36        b0 fffff880`023d23f0 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
37       210 fffff880`023d2600 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
38        50 fffff880`023d2650 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
39       180 fffff880`023d27d0 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
3a        30 fffff880`023d2800 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
3b        b0 fffff880`023d28b0 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
3c       210 fffff880`023d2ac0 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
3d        50 fffff880`023d2b10 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
3e       180 fffff880`023d2c90 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
3f        30 fffff880`023d2cc0 fffff960`0013ed7f win32k!xxxReceiveMessage+0x6cb
40        f0 fffff880`023d2db0 fffff960`0013f039 win32k!xxxRealSleepThread+0xb3
41        c0 fffff880`023d2e70 fffff960`000f52d3 win32k!xxxSleepThread+0x59
42        30 fffff880`023d2ea0 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
43       110 fffff880`023d2fb0 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
44        b0 fffff880`023d3060 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
45       210 fffff880`023d3270 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
46        50 fffff880`023d32c0 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
47       180 fffff880`023d3440 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
48        30 fffff880`023d3470 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
49        b0 fffff880`023d3520 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
4a       210 fffff880`023d3730 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
4b        50 fffff880`023d3780 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
4c       180 fffff880`023d3900 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
4d        30 fffff880`023d3930 fffff960`0013ed7f win32k!xxxReceiveMessage+0x6cb
4e        f0 fffff880`023d3a20 fffff960`0013f039 win32k!xxxRealSleepThread+0xb3
4f        c0 fffff880`023d3ae0 fffff960`000f52d3 win32k!xxxSleepThread+0x59
50        30 fffff880`023d3b10 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
51       110 fffff880`023d3c20 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
52        b0 fffff880`023d3cd0 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
53       210 fffff880`023d3ee0 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
54        50 fffff880`023d3f30 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
55       180 fffff880`023d40b0 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
56        30 fffff880`023d40e0 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
57        b0 fffff880`023d4190 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
58       210 fffff880`023d43a0 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
59        50 fffff880`023d43f0 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
5a       180 fffff880`023d4570 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
5b        30 fffff880`023d45a0 fffff960`0013ed7f win32k!xxxReceiveMessage+0x6cb
5c        f0 fffff880`023d4690 fffff960`0013f039 win32k!xxxRealSleepThread+0xb3
5d        c0 fffff880`023d4750 fffff960`000f52d3 win32k!xxxSleepThread+0x59
5e        30 fffff880`023d4780 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
5f       110 fffff880`023d4890 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
60        b0 fffff880`023d4940 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
61       210 fffff880`023d4b50 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
62        50 fffff880`023d4ba0 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
63       180 fffff880`023d4d20 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
64        30 fffff880`023d4d50 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
65        b0 fffff880`023d4e00 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
66       210 fffff880`023d5010 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
67        50 fffff880`023d5060 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
68       180 fffff880`023d51e0 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
69        30 fffff880`023d5210 fffff960`0013ed7f win32k!xxxReceiveMessage+0x6cb
6a        f0 fffff880`023d5300 fffff960`0013f039 win32k!xxxRealSleepThread+0xb3
6b        c0 fffff880`023d53c0 fffff960`000f52d3 win32k!xxxSleepThread+0x59
6c        30 fffff880`023d53f0 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
6d       110 fffff880`023d5500 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
6e        b0 fffff880`023d55b0 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
6f       210 fffff880`023d57c0 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
70        50 fffff880`023d5810 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
71       180 fffff880`023d5990 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
72        30 fffff880`023d59c0 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
73        b0 fffff880`023d5a70 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
74       210 fffff880`023d5c80 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
75        50 fffff880`023d5cd0 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
76       180 fffff880`023d5e50 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
77        30 fffff880`023d5e80 fffff960`0013ed7f win32k!xxxReceiveMessage+0x6cb
78        f0 fffff880`023d5f70 fffff960`0013f039 win32k!xxxRealSleepThread+0xb3
79        c0 fffff880`023d6030 fffff960`000f52d3 win32k!xxxSleepThread+0x59
7a        30 fffff880`023d6060 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
7b       110 fffff880`023d6170 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
7c        b0 fffff880`023d6220 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
7d       210 fffff880`023d6430 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
7e        50 fffff880`023d6480 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
7f       180 fffff880`023d6600 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
80        30 fffff880`023d6630 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
81        b0 fffff880`023d66e0 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
82       210 fffff880`023d68f0 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
83        50 fffff880`023d6940 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
84       180 fffff880`023d6ac0 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
85        30 fffff880`023d6af0 fffff960`0013ed7f win32k!xxxReceiveMessage+0x6cb
86        f0 fffff880`023d6be0 fffff960`0013f039 win32k!xxxRealSleepThread+0xb3
87        c0 fffff880`023d6ca0 fffff960`000f52d3 win32k!xxxSleepThread+0x59
88        30 fffff880`023d6cd0 fffff960`0013df9e win32k!xxxInterSendMsgEx+0x112a
89       110 fffff880`023d6de0 fffff960`0011db46 win32k!xxxSendMessageTimeout+0x1de
8a        b0 fffff880`023d6e90 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x14c9
8b       210 fffff880`023d70a0 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
8c        50 fffff880`023d70f0 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
8d       180 fffff880`023d7270 fffff960`0013e035 win32k!xxxDesktopWndProc+0x55
8e        30 fffff880`023d72a0 fffff960`0011dd76 win32k!xxxSendMessageTimeout+0x275
8f        b0 fffff880`023d7350 fffff960`000fea2e win32k!xxxRealDefWindowProc+0x16f9
90       210 fffff880`023d7560 fffff960`000feb3a win32k!xxxDefWindowProc+0x15e
91        50 fffff880`023d75b0 fffff960`000feaa5 win32k!xxxDesktopWndProcWorker+0x7a
92       180 fffff880`023d7730 fffff960`000f3fd7 win32k!xxxDesktopWndProc+0x55
93        30 fffff880`023d7760 fffff960`0013d105 win32k!xxxReceiveMessage+0x6cb
94        f0 fffff880`023d7850 fffff960`0013d6ad win32k!xxxRealInternalGetMessage+0x339
95        e0 fffff880`023d7930 fffff960`0010c790 win32k!xxxInternalGetMessage+0x35
96        40 fffff880`023d7970 fffff960`0010c667 win32k!xxxHandleDesktopMessages+0x50
97        90 fffff880`023d7a00 fffff960`000c5140 win32k!xxxDesktopThread+0x263
98        80 fffff880`023d7a80 fffff960`00147bad win32k!xxxCreateSystemThreads+0x64
99        30 fffff880`023d7ab0 fffff800`034f09d3 win32k!NtUserCallNoParam+0x39
9a        30 fffff880`023d7ae0 000007fe`fd4e1f1a nt!KiSystemServiceCopyEnd+0x13
9b           00000000`0241fb38 000007fe`fd4e3759 winsrv!ZwUserCallNoParam+0xa
9c         8 00000000`0241fb40 00000000`77a13865 winsrv!StartCreateSystemThreads+0x19
9d        30 00000000`0241fb70 00000000`00000000 ntdll!RtlUserThreadStart+0x25
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

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
        .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)
kb will then show the corrected stack.
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000406f8
Arg4: fffff88004afe4ec

Debugging Details:






BUILD_VERSION_STRING:  7601.24231.amd64fre.win7sp1_ldr.180810-0600






BIOS_DATE:  04/02/2012






BUGCHECK_P2: 80050031

BUGCHECK_P3: 406f8

BUGCHECK_P4: fffff88004afe4ec


TRAP_FRAME:  fffff80004b49e50 -- (.trap 0xfffff80004b49e50)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000004 rbx=0000000000000000 rcx=fffff880023d0014
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88004afe4ec rsp=fffff880023cfff0 rbp=fffffa800a6f91d0
r8=0000000000000044  r9=fffff88004b039b0 r10=fffffa8009cef1c0
r11=fffff880023d0840 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
fffff880`04afe4ec e88f51fdff      call    atikmdag+0xab680 (fffff880`04ad3680)
Resetting default scope


CPU_MHZ: c15

CPU_VENDOR:  GenuineIntel




CPU_MICROCODE: 6,2a,7,0 (F,M,S,R)  SIG: 25'00000000 (cache) 25'00000000 (init)


PROCESS_NAME:  csrss.exe



ANALYSIS_SESSION_TIME:  10-24-2018 14:19:20.0718

ANALYSIS_VERSION: 10.0.17763.1 amd64fre

STACK_OVERFLOW: Stack Limit: fffff880023d0000. Use (kF) and (!stackusage) to investigate stack usage.

STACKUSAGE_IMAGE: The module at base 0xFFFFF96000070000 was blamed for the stack overflow. It is using 23088 bytes of stack.

STACK_COMMAND:  .trap 0xfffff80004b49e50 ; kb

THREAD_SHA1_HASH_MOD_FUNC:  6a385cbb0f8ccdfe23d79c837887292e3a0343d4

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  a6b9b24f6a7c8d313955e42df514504db9c2022d

THREAD_SHA1_HASH_MOD:  12bfd209d07a227395ddd4f8fb373895e22f9deb

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  win32k.sys


IMAGE_VERSION:  6.1.7601.24204


BUCKET_ID:  X64_0x7f_8_STACK_USAGE_IMAGE_win32k.sys


TARGET_TIME:  2018-10-24T15:54:07.000Z

OSBUILD:  7601







OSNAME:  Windows 7

OSEDITION:  Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS



OSBUILD_TIMESTAMP:  2018-08-10 10:14:00


BUILDLAB_STR:  win7sp1_ldr

BUILDOSVER_STR:  6.1.7601.24231.amd64fre.win7sp1_ldr.180810-0600



FAILURE_ID_HASH_STRING:  km:x64_0x7f_8_stack_usage_image_win32k.sys

FAILURE_ID_HASH:  {9379fe1d-c62a-7f6a-5b2c-3449edfdc1b1}

Followup:     MachineOwner

Stack Usage By Function

      Size     Count  Module
0x00048260         2  nt!KiSystemServiceCopyEnd
0x00001500        14  win32k!xxxDesktopWndProcWorker
0x00000E70         7  win32k!xxxRealDefWindowProc
0x00000E70         7  win32k!xxxRealDefWindowProc
0x00000770         7  win32k!xxxInterSendMsgEx
0x00000690         7  win32k!xxxReceiveMessage
0x000004D0         7  win32k!xxxSendMessageTimeout
0x000004D0         7  win32k!xxxSendMessageTimeout
0x00000480         6  win32k!xxxRealSleepThread
0x00000460        14  win32k!xxxDefWindowProc
0x000002C0         1  nt!KeWaitForMultipleObjects
0x000002A0        14  win32k!xxxDesktopWndProc
0x00000240         1  mfeaack
0x00000220         1  nt!ObOpenObjectByPointerWithTag
0x00000190         1  nt!KiInterruptDispatch
0x00000190         1  mfeaack
0x00000160         1  sk
0x00000150         7  win32k!xxxSleepThread
0x00000140         1  nt!KiBugCheckDispatch
0x00000140         1  mfeaack
0x00000130         1  nt!NtReadFile
0x00000130         1  sk
0x00000120         1  sk
0x00000110         1  nt! ?? ::NNGAKEGL::`string'
0x000000E0         1  sk
0x000000E0         1  mfeaack
0x000000E0         1  win32k!xxxRealInternalGetMessage
0x000000D0         1  sk
0x000000C0         1  win32k!xxxRealSleepThread
0x000000B0         1  mfeaack
0x00000090         1  nt!KiCommitThreadWait
0x00000090         1  atikmdag
0x00000090         1  atikmdag
0x00000090         1  win32k!xxxHandleDesktopMessages
0x00000080         1  nt!KiDeliverApc
0x00000080         1  nt!ObpCallPreOperationCallbacks
0x00000080         1  nt!ObpPreInterceptHandleCreate
0x00000080         1  sk
0x00000080         1  atikmdag
0x00000080         1  atikmdag
0x00000080         1  mfeaack
0x00000080         1  win32k!xxxDesktopThread
0x00000070         1  sk
0x00000070         1  mfeaack
0x00000070         1  mfeaack
0x00000060         1  sk
0x00000060         1  win32k!StartDeviceRead
0x00000050         1  nt!KeAcquireSpinLockRaiseToDpc
0x00000050         1  nt!ObOpenObjectByPointer
0x00000050         1  mfeaack
0x00000040         1  sk
0x00000040         1  mfeaack
0x00000040         1  win32k!xxxInternalGetMessage
0x00000030         1  winsrv!StartCreateSystemThreads
0x00000030         1  sk
0x00000030         1  sk
0x00000030         1  mfehidk
0x00000030         1  mfehidk
0x00000030         1  atikmpag
0x00000030         1  atikmdag
0x00000030         1  atikmdag
0x00000030         1  mfeaack
0x00000030         1  mfeaack
0x00000030         1  win32k!xxxCreateSystemThreads
0x00000030         1  win32k!NtUserCallNoParam
0x00000030         1  win32k!InputApc
0x00000008         1  winsrv!ZwUserCallNoParam
0x00000008         2  nt!KeBugCheckEx
0x00000008         1  nt!KiServiceLinkage

Total Size: 0x0004FCC8

Stack Usage By Module

      Size     Count  Module
0x00048F10        17  nt
0x00005A30       106  win32k
0x000008F0        12  mfeaack
0x00000750        11  sk
0x00000280         6  atikmdag
0x00000060         2  mfehidk
0x00000038         2  winsrv
0x00000030         1  atikmpag

Total Size: 0x0004FCC8

My System SpecsSystem Spec
26 Oct 2018   #2
wither 2

Windows 7 Pro SP1 64 bit

Hey "regular old dan", please follow the instructions provided here and post the .zip file-

Blue Screen of Death (BSOD) Posting Instructions
My System SpecsSystem Spec
27 Oct 2018   #3

Windows 10 Pro

AFAIK the raw stack should be inspected to see where it all started. The address of the module where Windbg says it started doesn't look to be in the stack.
You might also want to look at the KTHREAD data structure and Thread Environment Block.

It looks like you don't have Windbg configured so the required symbols aren't downloaded.
My System SpecsSystem Spec

29 Oct 2018   #4
regular old dan

Windows 7 Professional

Unfortunately there's zero chance of being allowed to run a 3rd party utility like DM Log Collector on these machines, but anything it was going to provide I could gather manually and screen for memory value leaks. That's the nature of some big corporate systems unfortunately.

That KTHREAD pointer was great! Found and its KTHREAD line, and now just need to try random pointers in the stack until a 'valid' KTHREAD struct shows up. I have symbols downloading successfully, obviously not for sk.sys/mcafee/ATI code since they're not publically available, are there additional symbol servers I can point to? I didn't think Microsoft would make symbols for things like kernel local vars available to the general public, but if so that'd be perfect.

I've done a lot of C/assembly debugging in the past, but having no function argument descriptions for these xxx win32k functions makes it hard to get started in the heap.
My System SpecsSystem Spec
29 Oct 2018   #5

Windows 10 Pro

You could run the tool and scan the content of the zip file before uploading it.
The tool leaves a batch file in the temp folder which it runs, this file could also be scanned.

Regardless of what some say, I'm not an expert at BSOD dump analysis and it sounds like you get much further with it than I can. Though I rarely see dumps which are actually capable of getting in the heap, but I primarily use mini kernel dumps for which patterns are most important.

I've never seen xxx calls in win32k before, a little research indicates it means the function may leave the critical section for which consequently the Microsoft engineers have to be careful with the way the code is written.
My System SpecsSystem Spec
02 Nov 2018   #6
regular old dan

Windows 7 Professional

This issue was not caused by antivirus software, but apparently an unfortunate set of circumstances. A Microsoft debug engineer found that:

- multiple applications, such as Word 365, Skype for Business, BgInfo and others, are spawning top-level windows that have the WM_CHILD property set
- when messages WM_CHANGEUISTATE or WM_UPDATEUISTATE are sent to those windows, the parent ultimately processing them ends up being the csrss.exe-spawned desktop thread, as they were technically 'child' windows but were top-level, and the only window above that is the desktop
- the desktop thread in win32k.sys usually wouldn't process these messages, and doesn't attempt to as of windows 10, but in windows 7's case it forwarded them to the default window proc associated with the destinations
- if whatever was supposed to eventually process these messages fails to consume them, they will keep eating up stack space in the win32k.sys desktop thread - 3 or 4 kbytes or so per stuck message. Not all messages become stuck like this, there must be another issue somewhere preventing the destination processes (Word, etc.) from retiring the messages sometimes
- if this happens enough and the offending applications aren't all terminated, eventually the kernel stack runs out of space leading to BSOD

The workaround is to kill off all top-level WM_CHILD window-owning applications that receive these messages periodically, which will unwind the kernel stack, or just logoff/logon since csrss.exe kills off the desktop thread at that point. I hope this helps someone else some day.
My System SpecsSystem Spec

 BSOD double fault, win32k.sys using excessive kernel stack space

Thread Tools

Similar help and support threads
Thread Forum
BSOD 0x0000007f Exception Double Fault
BSOD Help and Support
BSOD Exception Double Fault
************* Symbol Path validation summary ************** Response Time (ms) Location Deferred SRV*C:\Windows\symbol_cache*Symbol information Symbol search path is: SRV*C:\Windows\symbol_cache*Symbol information Executable...
BSOD Help and Support
BSOD while playing dota 2 kernel stack driver error
I have had multiple BSODs most frequently while playing Dota 2. they usually happen in around 50+ mins in game and I have had them since about 2 months ago avery other game runs without problems. I Did a driver verifier and ram check as was instructed on other posts. Ram check did not show...
BSOD Help and Support
BSOD- need to replace faulty driver on kernel stack
Hello anyone who can help me. This week i started getting these and they are sporadic, sometimes happening frequently almost as soon as windows appears. I have used driver sweeper to clean all drivers and this helped for a while. I have now tried to use combofix but this causes the BSOD every...
BSOD Help and Support
BSOD on Windows 7 64bit - kernel stack inpage error
Hey guys, so basically i've had this come up about three times today, all while i was using my pc as normal. its almost brand new, only been used for the last week or two and virus scans show up no viruses. System restore failed and hardware memory checks said nothing was wrong, as did...
BSOD Help and Support

Our Sites

Site Links

About Us

Find Us

Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

Designer Media Ltd

All times are GMT -5. The time now is 07:06.
Twitter Facebook Google+