win32k message queue problem

[Hartmut Birr]

Hi,
it seems there exist a problem with the message queues. If a process is
terminated (killed) from outside, the thread message queue is deleted
before the last window is deleted. If there is a message (key or mouse)
for this window, the window does access the already freed message queue.
This will crash the system. Possible it is related to the paged pool
memory corruption bug. I've a (dirty) fix for this problem.
- Hartmut
Index: subsys/win32k/ntuser/window.c
===================================================================
--- subsys/win32k/ntuser/window.c       (Revision 16707)
+++ subsys/win32k/ntuser/window.c       (Arbeitskopie)
@@ -1577,6 +1577,7 @@
       IntSetMenu(WindowObject, hMenu, &MenuChanged);
     }
   WindowObject->MessageQueue = PsGetWin32Thread()->MessageQueue;
+  IntReferenceMessageQueue(WindowObject->MessageQueue);
   WindowObject->Parent = (ParentWindow ? ParentWindow->Self : NULL);
   if((OwnerWindow = IntGetWindowObject(OwnerWindowHandle)))
   {
@@ -2180,7 +2181,7 @@
   if (Window->MessageQueue->CaptureWindow == Window->Self)
     Window->MessageQueue->CaptureWindow = NULL;
   IntUnLockMessageQueue(Window->MessageQueue);
-
+  IntDereferenceMessageQueue(Window->MessageQueue);
   /* Call hooks */
 #if 0 /* FIXME */
   if (HOOK_CallHooks(WH_CBT, HCBT_DESTROYWND, (WPARAM) hwnd, 0, TRUE))

[James Tabor]

Hi,
Hartmut Birr wrote:
>   Hi,
>  it seems there exist a problem with the message queues. If a process is
>  terminated (killed) from outside, the thread message queue is deleted
>  before the last window is deleted. If there is a message (key or mouse)
>  for this window, the window does access the already freed message queue.
>  This will crash the system. Possible it is related to the paged pool
>  memory corruption bug. I've a (dirty) fix for this problem.
>  - Hartmut
>   
I tested this patch with AbiWord. I selected one of the color selector down
menus. This always generates an bug check and the program terminates with
window threads still resident. Now I exit explorer to shutdown the system.
Instead of locking up and hitting the reset button, the system shut down
normally. Was this test close to what you have seen? Or am I off in left field?
Thanks,
James

[Hartmut Birr]

James Tabor wrote:
>   Hi,
>  Hartmut Birr wrote:
> >   Hi,
> >  it seems there exist a problem with the message queues. If a process is
> >  terminated (killed) from outside, the thread message queue is deleted
> >  before the last window is deleted. If there is a message (key or mouse)
> >  for this window, the window does access the already freed message queue.
> >  This will crash the system. Possible it is related to the paged pool
> >  memory corruption bug. I've a (dirty) fix for this problem.
> >  - Hartmut
> >  
>  I tested this patch with AbiWord. I selected one of the color selector
>  down
>  menus. This always generates an bug check and the program terminates with
>  window threads still resident. Now I exit explorer to shutdown the
>  system.
>  Instead of locking up and hitting the reset button, the system shut down
>  normally. Was this test close to what you have seen? Or am I off in
>  left field?
>  Thanks,
>  James 
Hi,
I've extend the delay in ShutdownThreadMain to 10sec. If you log off
while some applications are running (possible it must be a console
application) and you hit a key or click a mouse button on the blue
screen, your get the following crash message.
- Hartmut
...
(ntoskrnl\ps\kill.c:421) PspExitNormalApc called: 0x80e54940 (proc:
0x80e2fcb8, 'umpnpmgr.exe')
(ntoskrnl\ps\kill.c:441) Initializing User-Mode APC
(ntoskrnl\ke\apc.c:276) Inserting the Thread Exit APC for 'umpnpmgr.exe'
into the Queue
(ntoskrnl\ps\kill.c:392) PsExitSpecialApc called: 0x812ce890 (proc:
0x80a92698, 'csrss.exe')
(subsys\win32k\ntuser\windc.c:763) [000001b8] GetDC() without ReleaseDC()!
(ntoskrnl\ps\kill.c:392) PsExitSpecialApc called: 0x80db37b0 (proc:
0x80a92698, 'csrss.exe')
KeBugCheckWithTf at ntoskrnl\ke\catch.c:235
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
The problem seems to be caused by the following file: win32k.sys
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x9d6290fa,0x00000000,0xcdcdcdcd)
***    win32k.sys - Address 0x9d6290fa base at 0x9d5ea000, DateStamp 0x0
Page Fault Exception: 14(2)
Processor: 0 CS:EIP 8:9d6290fa <win32k.sys:3f0fa
(subsys/win32k/ntuser/msgqueue.c:4860 (MsqTranslateMouseMessage))>
cr2 cdcdcdcd cr3 7896000 Proc: 80a92698 Pid: 78 <csrss.exe> Thrd:
80db64c8 Tid: b0
DS 10 ES 10 FS 30 GS 10
EAX: 8d101120   EBX: 8d3fa300   ECX: 8d101100
EDX: cdcdcdcd   EBP: 9dcd4b90   ESI: 8d084fa8   ESP: 9dcd4b08
EDI: 8d3fa300   EFLAGS: 00000246 kESP 9dcd4b08 kernel stack base 9dcd2000
Frames:
<win32k.sys:3f7e3 (subsys/win32k/ntuser/msgqueue.c:594
(MsqPeekHardwareMessage))>
<win32k.sys:4053a (subsys/win32k/ntuser/msgqueue.c:1247 (MsqFindMessage))>
<win32k.sys:3b772 (subsys/win32k/ntuser/message.c:689 (IntPeekMessage))>
<win32k.sys:3baf1 (subsys/win32k/ntuser/message.c:882 (IntWaitMessage))>
<win32k.sys:3bc8a (subsys/win32k/ntuser/message.c:988 (NtUserGetMessage))>
<ntoskrnl.exe:97152 ({standard input}:177 (KiSystemService))>
<user32.dll:32305 (lib/user32/windows/message.c:1167 (GetMessageW))>