[ros-kernel] crash in win32k

[Hartmut Birr]

Hi,

I get the same result as previous applying your patch. An other problem
is that I can't boot ros with the kernel debugger enabled and loading
all symbol files. It seems that the 6MB room between 2MB an 8MB is too
short. Currently I've deleted ntoskrnl.sym.

- Hartmut

(dirwr.c:85) vfatFindDirSpace(DeviceExt c4765000, pDirFcb c482b738,
nbSlots 1, start ce172ce8)
(dirwr.c:87) 59 2003
(dirwr.c:142) found a free run at 59
(dirwr.c:170) nbSlots 1 entry number 59
(eng/handle.c:64) CreateGDIHandle: Out of available handles!!!
Assertion ((void *)0) != Dc->CombinedClip failed at objects/cliprgn.c:89
Bug detected (code 0 param 0 0 0 0)
  The bug code is undefined. Please use an existing code instead.

Frames: 
<ntoskrnl.exe: a3ec> 
<ntoskrnl.exe: a40c> 
<win32k.sys: 2e908 (objects/cliprgn.c:89 (CLIPPING_UpdateGCRegion))> 
<win32k.sys: 2ef9c (objects/cliprgn.c:331 (NtGdiSelectClipRgn))> 
<win32k.sys: 33386 (objects/dc.c:1195 (NtGdiSetDCState))> 
<win32k.sys: 24112 (ntuser/windc.c:214 (DceReleaseDC))> 
<win32k.sys: 2494f (ntuser/windc.c:596 (NtUserReleaseDC))> 
<ntoskrnl.exe: 3720> 
<user32.dll: ca53 (misc/win32k.c:154 (WinHelpW))> 
<win32csr.dll: 7834 (guiconsole.c:290 (GuiConsoleUpdateBitmap))> 
<win32csr.dll: 79fb (guiconsole.c:351 (GuiIntDrawRegion))> 
<win32csr.dll: 7a70 (guiconsole.c:376 (GuiInvalidateCell))> 
<win32csr.dll: 7be4 (guiconsole.c:421 (GuiWriteStream))> 
<win32csr.dll: 20e5 (conio.c:497 (ConioWriteConsole))> 
<win32csr.dll: 2cb2 (conio.c:871 (CsrWriteConsole))> 
<csrss.exe: 1d3a (api/wapi.c:87 (CsrApiCallHandler))> 
<csrss.exe: 1e8f (api/wapi.c:140 (Thread_Api2))>

> -----Original Message-----
> From: ros-kernel-bounces at reactos.com 
> [mailto:ros-kernel-bounces at reactos.com] On Behalf Of Filip Navara
> Sent: Sunday, March 14, 2004 3:26 PM
> To: ReactOS Kernel List
> Subject: Re: [ros-kernel] crash in win32k
> 
> 
> 
> Hi,
> 
> I'm sorry that I can't debug it myself now. It looks pretty 
> much like a 
> big handle leak. Here is my *very hacky* patch that I'm using for 
> debugging such handle leaks:
> www.volny.cz/xnavara/ooghII.diff. It prints out all allocated 
> handles as 
> soon as GDI runs out of handles including complete trace of where the 
> handles were allocated. Typically it's pretty obvious where 
> the leak is 
> and so it shouldn't be hard to solve.
> 
> Regards,
> Filip
>