Re: [ros-dev] Service Control Manager, Plug and Pray, SMB and RPC

[Steven Edwards]

--- Eric Kohl [e-mail] wrote:
> IMHO, adding missing features to WIDL and fixing resulting bugs in 
> rpcrt4 is much more important right now. Access to remote machines, new 
> transports (tcp, udp, http, etc.) and a dynamic endpoint mapper (aka 
> rpcss) is not that important.

Would it be possible to go ahead and port some of the Wine advapi32 SCM code? Its able to install
and run services such as the Windows Installer so that might solve a few problems we are facing
with the Msi service and CoLinux.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

[Eric Kohl]

Steven Edwards wrote:
> Would it be possible to go ahead and port some of the Wine advapi32 SCM code? Its able to install
> and run services such as the Windows Installer so that might solve a few problems we are facing
> with the Msi service and CoLinux.

Sure, this is possible but I'm going to replace this code by RPC-based 
code as soon as possible. I have an almost-working implementation of 
OpenSCManagerA/W and CloseServiceHandle in my source-tree.

Which service manager functions do you need the most? I'll add the 
required features to WIDL next.

Unfortunately ReactOS is causing me some headache because it bugchecks 
in CSRSS(??) while booting and I couldn't figure out what goes wrong.

Regards,
Eric

[Royce Mitchell III]

Eric Kohl wrote:
> Sure, this is possible but I'm going to replace this code by RPC-based 
> code as soon as possible. I have an almost-working implementation of 
> OpenSCManagerA/W and CloseServiceHandle in my source-tree.
>
> Which service manager functions do you need the most? I'll add the 
> required features to WIDL next.
>
> Unfortunately ReactOS is causing me some headache because it bugchecks 
> in CSRSS(??) while booting and I couldn't figure out what goes wrong.
>
> Regards,
> Eric

Part of the reason he's bringing this up is because I was asking what 
was necessary to get working before we could dynamically load drivers 
through SCM. I'm working on learning driver development, but want to do 
it in ReactOS.

Anyways, these functions look most necessary...

OpenSCManager
CreateService
ControlService
OpenService
CloseServiceHandle
DeleteService
QueryServiceStatus
EnumServicesStatus

[Eric Kohl]

Royce Mitchell III wrote:
> Part of the reason he's bringing this up is because I was asking what 
> was necessary to get working before we could dynamically load drivers 
> through SCM. I'm working on learning driver development, but want to do 
> it in ReactOS.
>
> Anyways, these functions look most necessary...
>
> OpenSCManager
> CreateService
> ControlService
> OpenService
> CloseServiceHandle
> DeleteService
> QueryServiceStatus
> EnumServicesStatus

All functions except for ControlService, QueryServiceStatus and 
EnumServiceStatus are supported by the current WIDL. The functions above 
require support for 'pointers to structs'. It will take about a weekend 
to implement and test this feature on Windows but this doesn't mean it 
will work on ReactOS because rpcrt4 might need some work either.

Then we only need to implement these functions in the SCM.

Eric

[ea]

Eric Kohl wrote:
> Unfortunately ReactOS is causing me some headache because it bugchecks 
> in CSRSS(??) while booting and I couldn't figure out what goes wrong.

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

Emanuele

[Eric Kohl]

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
> csrss calls (\SmApiPort) SM to register IMAGE_SUBSYSTEM_WINDOWS_CUI
> SM calls back (\Windows\SbApiPort)
> csrss sees the green light and bootstraps (initializes)
> 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

[ea]

Eric Kohl wrote:
> 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.

No changes in win32csr by me (none I actually committed; only in an 
offline local tree). Also plug-in loader is untouched (no docs: looking 
into it to understand how it works).

The major changes are:
- sm loads the required subsystems reading the registry
- csrss needs ok from sm to boot (registering)
- winlogon is child of csrss not sm (for future multiuser w32)

To do:
- DEBUG subsystem may be an external native process
- sm dies if any required subsystem dies (actually only win32)
- sm kills any subsystem that doesn't not follow the registration protocol

Maybe a race condition between win32csr.dll and winlogon? When it was 
run by sm it was done after csrss had notified sm signalling a named 
event to day boot was OK.

Emanuele

[Hartmut Birr]

Eric Kohl wrote:
> 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
> > csrss calls (\SmApiPort) SM to register IMAGE_SUBSYSTEM_WINDOWS_CUI
> > SM calls back (\Windows\SbApiPort)
> > csrss sees the green light and bootstraps (initializes)
> > 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

The real bug starts here. NtUserToUnicodeEx trys to allocate to much
from nonpaged pool. This means cchBuff is to large. The only caller of
NtUserToUnicodeEx is ConioProcessKey. ConioProcessKey calls  ToUnicodeEx
(which calls NtUserToUnicodeEx) with cchBuff = 2. Something is wrong in
the paramter translation between real and protected mode.

- Hartmut

[Eric Kohl]

Hartmut Birr wrote:
> The real bug starts here. NtUserToUnicodeEx trys to allocate to much
> from nonpaged pool. This means cchBuff is to large. The only caller of
> NtUserToUnicodeEx is ConioProcessKey. ConioProcessKey calls  ToUnicodeEx
> (which calls NtUserToUnicodeEx) with cchBuff = 2. Something is wrong in
> the paramter translation between real and protected mode.

I set cchBuff = 2 inside of NtUserToUnicodeEx and this fixes the 
following warnings:
> (mm/npool.c:1626) Trying to allocate 3758215216 bytes from nonpaged
> pool - nothing suitable found, returning NULL
> (ntuser/keyboard.c:849) ExAllocatePool(-536752086) failed

But the bugcheck still happens. So, I think it is related to
> MenuInit(): SystemParametersInfoW(SPI_GETNONCLIENTMETRICS) failed!

Because the bugcheck happens in IntGetMenuObject (in win32k.sys).

Regards,
Eric

[Hartmut Birr]

Eric Kohl wrote:
> Hartmut Birr wrote:
> > The real bug starts here. NtUserToUnicodeEx trys to allocate to much
> > from nonpaged pool. This means cchBuff is to large. The only caller of
> > NtUserToUnicodeEx is ConioProcessKey. ConioProcessKey calls  ToUnicodeEx
> > (which calls NtUserToUnicodeEx) with cchBuff = 2. Something is wrong in
> > the paramter translation between real and protected mode.
>
> I set cchBuff = 2 inside of NtUserToUnicodeEx and this fixes the
> following warnings:

I've the feeling that there exist an index mismatch of the called
functions. Possible user32 and win32k use different versions of w32ksvc.db.

- Hartmut

[Hartmut Birr]

Hi,

can you delete

subsys/win32k/main/svctab.c
subsys/win32k/main/svctabm.o
lib/gdi32/misc/win32k.S
lib/gdi32/misc/win32k.o
lib/user32/misc/win32k.S
lib/user32/misc/win32k.o

and build and try it again?

- Hartmut

Eric Kohl wrote:
> 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
> > csrss calls (\SmApiPort) SM to register IMAGE_SUBSYSTEM_WINDOWS_CUI
> > SM calls back (\Windows\SbApiPort)
> > csrss sees the green light and bootstraps (initializes)
> > 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
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[James Tabor]

Hartmut Birr wrote:
> Hi,

BTW, I have 1,611 handles open now. It looks like it's a handle hog!
James

[Eric Kohl]

Hartmut Birr wrote:
> can you delete
>
> subsys/win32k/main/svctab.c
> subsys/win32k/main/svctabm.o
> lib/gdi32/misc/win32k.S
> lib/gdi32/misc/win32k.o
> lib/user32/misc/win32k.S
> lib/user32/misc/win32k.o
>
> and build and try it again?

Thank you very much, Hartmut!

I found an outdated file lib/user32/misc/win32k.c that was compiled 
instead of lib/user32/misc/win32k.s. The result was a wrong system call 
id (0x1206 instead of 0x1203) for NtUserSystemParametersInfo().

ReactOS is working again!

Regards,
Eric

[ea]

Eric Kohl wrote:
> Thank you very much, Hartmut!
>
> I found an outdated file lib/user32/misc/win32k.c that was compiled 
> instead of lib/user32/misc/win32k.s. The result was a wrong system 
> call id (0x1206 instead of 0x1203) for NtUserSystemParametersInfo().
>
> ReactOS is working again!

Thank you from me too, Hartmut! It seems you can always find the needle, 
no matter how large the heap is. This explains why someone else was 
required to trow away the working copy and co again.
We should probably set another rule for the well behaving 
developer/commiter: add a warning to make-clean before updating, if the 
changes we are going to commit do modify the clean logic.

Emanuele

[Ge van Geldorp]

> From: ea
>
> We should probably set another rule for the well behaving 
> developer/commiter: add a warning to make-clean before 
> updating, if the changes we are going to commit do modify
> the clean logic.

What works for me is to first do "make clean", then update, then rebuild.

Gé van Geldorp.