[ros-dev] win32k crash on shutdown details

[Royce Mitchell III]

FWIW, Alex is also experiencing this problem...

Basically while shutting down for reboot, I hit Ctrl+Alt on the 
keyboard, and it crashed.

Here's the dump:

(smss.c:85) SM: Process terminated!
(ke/error.c:54) Hard error c000021a
(ke/catch.c:142) Unhandled UserMode exception, terminating thread
KeBugCheckWithTf at ke/catch.c:177
Bug detected (code 1e param 0 0 0 0)
  KMODE_EXCEPTION_NOT_HANDLED
 
 
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:9d5b40ef <win32k.sys: 180ef>
cr2 cdcdcef1 cr3 27000 Proc: 8048d8e0 Pid: 4 <System> Thrd: 80670050 Tid: 78
DS 10 ES 10 FS 30 GS 10
EAX: cdcdcdcd   EBX: 9d5b3db2   ECX: 80593a50
EDX: 80670084   EBP: 9d70fdd8   ESI: 00000000   ESP: 9d70fcbc
EDI: 00000000   EFLAGS: 00000282 kESP 9d70fcbc kernel stack base 9d70d000
Frames:
<ntoskrnl.exe: 33f0>

here's the assembly instruction where we crashed:
<win32k.sys: 180ef> cmpl   $0x0,0x124(%eax)

here's what addr2line gives:
C:\cvs\reactos\subsys\win32k>a 180ef
C:/cvs/reactos/subsys/win32k/ntuser/input.c:380

subsys/win32k/ntuser/input.c:380:
 if (FocusThread && FocusThread->Tcb.Win32Thread &&

so FocusThread is 0xcdcdcdcd, which means that the FocusQueue holding it is getting
deleted out from under us.

after initial examination, we aren't ref counting the desktop or the queue when we
obtain it via IntGetFocusMessageQueue().

as this bug is occuring on shutdown, I think the most proper solution is to reference the
msgqueue until we're done with it there in ntuser/input.c.

However, in order to safely reference the msgqueue, it seems we really need to reference
the desktop at least long enough to obtain the msgqueue pointer and reference it.

This sounds very slow, so I'm wondering if there's a better fix than that...

I was thinking we could add a "shutdown hack" for this, by at the very least
killing InputDesktop sooner, but it seems that might not help in situations where
we're killing one of many desktops.

Anyways, I'm not confident what should be done in this case, so I'm passing this
information to the list in hopes that someone more familiar with the msgqueue code can fix
it.

Thanks,

Royce Mitchell III

<ntoskrnl.exe: 33f0>