bugchecks in CSRSS (was Re: [ros-dev] Service Control Manager, Plug and Pray, SMB and RPC)

Eric Kohl eric.kohl at t-online.de
Mon Mar 28 20:26:20 CEST 2005


ea wrote:

> After my last changes, somebody was required to clean the local 
> repository to boot successfully. It's not clear why.  The registry is 
> necessary now to bootstrap, but if you get a bugcheck in the csrss 
> process, it seems the SM is OK with it. The only place I imagine a 
> bugcheck can happen is init.c, where
> 
> 1. csrss calls (\SmApiPort) SM to register IMAGE_SUBSYSTEM_WINDOWS_CUI
> 2. SM calls back (\Windows\SbApiPort)
> 3. csrss sees the green light and bootstraps (initializes)
> 4. csrss calls SM_COMPLETE_SESSION to tell SM it's OK

My debug log looks like this:

DriverBase for \??\C:\reactos\system32\win32k.sys: 9d94a000
DriverBase for \??\C:\reactos\system32\freetype.dll: 9da33000
DriverBase for \SystemRoot\System32\kbdus.dll: 9dab8000
ReactOS Client/Server Run-Time 0.3-SVN (Build 20050328-r14362)
(mm/npool.c:1626) Trying to allocate 3758215216 bytes from nonpaged pool 
- nothing suitable found, returning NULL
(ntuser/keyboard.c:849) ExAllocatePool(-536752086) failed
MenuInit(): SystemParametersInfoW(SPI_GETNONCLIENTMETRICS) failed!
KeBugCheckWithTf at ke/catch.c:223
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

KMODE_EXCEPTION_NOT_HANDLED
Technical information:

*** STOP: 0x0000001E (0xc0000005,0x9d960b08,0x00000000,0xf000e835)

***    win32k.sys - Address 0x9d960b08 base at 0x9d94a000, DateStamp 0x0

Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:9d960b08 <win32k.sys: 16b08>
cr2 f000e835 cr3 1eb05000 Proc: 809a6630 Pid: 7c <csrss.ex> Thrd: 
809b0740 Tid: 80
DS 10 ES 10 FS 30 GS 23
EAX: f000e815   EBX: 77ea9210   ECX: 77ea9210
EDX: 00000000   EBP: 9ddb1d40   ESI: 0064fe78   ESP: 9ddb1cc4
EDI: 9ddb1d74   EFLAGS: 00010282 kESP 9ddb1cc4 kernel stack base 9ddaf000
Frames:
<win32k.sys: 18171>
<ntoskrnl.exe: 318b>
<77E6C08E>

The given addresses are:
0x9d960b08 <win32k.sys: 16b08>   IntGetMenuObject
            <win32k.sys: 18171>   NtUserCheckMenuItem
            <ntoskrnl.exe: 318b>  KeReturnFromSystemCall
0x77E6C08E <user32.dll: c08e>    NtUserCallTwoParam


I think the bugcheck happens when csrss.exe loads win32csr.dll and thus 
user32.dll and user32 gets initialized.

Did anything change in the initialization within the last month? I made 
a full rebuild on March 2nd and it installed perfectly.


Eric





More information about the Ros-dev mailing list