KeBugCheck

[James Tabor]

Hi!

This is svn build 14542,

(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi
32.dll
(KERNEL32:mem/global.c:412) Memory Load: 23
(KERNEL32:mem/global.c:412) Memory Load: 23
(KERNEL32:mem/global.c:412) Memory Load: 23
(KERNEL32:mem/global.c:412) Memory Load: 23
(MSVCRT:io/open.c:103) not valid fd 0, g_fdend 5, fdinfo 7802d2f0, bucket 7802d2
f0, fdflags 0
(MSVCRT:io/open.c:700) _setmode: inval fd (0)
(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi
32.dll
ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
KeBugCheck at ex/handle.c:909
A problem has been detected and ReactOS has been shut down to prevent damage to
your computer.

The bug code is undefined. Please use an existing code instead.

Technical information:

*** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000)

Frames:
<ntoskrnl.exe:dbe3 (ke/bug.c:459 (KeBugCheckEx))>
<ntoskrnl.exe:dc03 (ke/bug.c:479 (KeBugCheck))>
<ntoskrnl.exe:3dcee (ex/handle.c:909 (ExMapHandleToPointer))>
<ntoskrnl.exe:92b23 (ob/handle.c:768 (ObReferenceObjectByHandle))>
<ntoskrnl.exe:3b3f2 (ex/event.c:476 (NtSetEvent))>
<ntoskrnl.exe:3c22 (/tmp/ccAGlOXR.s:178 (KiSystemService))>
<ntdll.dll:a414 (rtl/critical.c:502 (RtlpUnWaitCriticalSection))>

Entered debugger on embedded INT3 at 0x0008:0x800064be.
kdb:>

No keyboard,
James

[Hartmut Birr]

James Tabor wrote:
> Hi!
>
> This is svn build 14542,
>
> (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000)
> C:\ReactOS\System32\gdi
> 32.dll
> ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
> KeBugCheck at ex/handle.c:909

This is a little bit stupid. Why is 0 greater than APC_LEVEL? Do you use
an optimized build where oarch is set to i586 or better?

- Hartmut

[James Tabor]

Hi!
Hartmut Birr wrote:
> James Tabor wrote:
> > Hi!
> >
> > This is svn build 14542,
> >
> > (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000)
> > C:\ReactOS\System32\gdi
> > 32.dll
> > ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
> > KeBugCheck at ex/handle.c:909
>
> This is a little bit stupid. Why is 0 greater than APC_LEVEL? Do you use
> an optimized build where oarch is set to i586 or better?
> Hartmut

Hum?
NO,  OARCH := i486, KDBG := 1 and DBG := 1.
James

[Hartmut Birr]

James Tabor wrote:
> Hi!
> Hartmut Birr wrote:
> > James Tabor wrote:
> > > Hi!
> > >
> > > This is svn build 14542,
> > >
> > > (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000)
> > > C:\ReactOS\System32\gdi
> > > 32.dll
> > > ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
> > > KeBugCheck at ex/handle.c:909
> >
> > This is a little bit stupid. Why is 0 greater than APC_LEVEL? Do you use
> > an optimized build where oarch is set to i586 or better?
> > Hartmut
>
> Hum?
> NO,  OARCH := i486, KDBG := 1 and DBG := 1.
> James

I get weird crashs if I set OARCH to pentium4. Looking to te PAGED_CODE
macro in ExMapHandleToPointer:

PHANDLE_TABLE_ENTRY
ExMapHandleToPointer(IN PHANDLE_TABLE HandleTable,
                     IN LONG Handle)
{
80027801:    55                       push   %ebp
80027802:    89 e5                    mov    %esp,%ebp
80027804:    83 ec 08                 sub    $0x8,%esp
  PHANDLE_TABLE_ENTRY HandleTableEntry;

PAGED_CODE();
80027807:    e8 84 3c 06 00           call   8008b490 _KeGetCurrentIrql@0
8002780c:    3c 01                    cmp    $0x1,%al
8002780e:    76 49                    jbe    80027859
<_ExMapHandleToPointer+0x58>
80027810:    e8 7b 3c 06 00           call   8008b490 _KeGetCurrentIrql@0
80027815:    25 ff 00 00 00           and    $0xff,%eax
8002781a:    50                       push   %eax
8002781b:    68 8d 03 00 00           push   $0x38d
80027820:    68 70 13 0b 80           push   $0x800b1370
80027825:    68 7c 13 0b 80           push   $0x800b137c
8002782a:    e8 21 b7 ff ff           call   80022f50 <_DbgPrint>
...

The first call to KeGetCurrentIrql returns an irql which is higher than
APC level. The second call returns PASSIVE_LEVEL. This can't occur
because there is no function which  raise or lower the irql. It may be
possible , that a task switch occur before and after the first call to
KeGetCurrentIrql and which has set the irql to a wrong value.

- Hartmut

[James Tabor]

Hi,
Hartmut Birr wrote:
> I get weird crashs if I set OARCH to pentium4. Looking to te PAGED_CODE
> macro in ExMapHandleToPointer:
>
> PHANDLE_TABLE_ENTRY
> ExMapHandleToPointer(IN PHANDLE_TABLE HandleTable,
>                      IN LONG Handle)
> {
> 80027801:    55                       push   %ebp
> 80027802:    89 e5                    mov    %esp,%ebp
> 80027804:    83 ec 08                 sub    $0x8,%esp
>   PHANDLE_TABLE_ENTRY HandleTableEntry;
>
> PAGED_CODE();
> 80027807:    e8 84 3c 06 00           call   8008b490 _KeGetCurrentIrql@0
> 8002780c:    3c 01                    cmp    $0x1,%al
> 8002780e:    76 49                    jbe    80027859
> <_ExMapHandleToPointer+0x58>
> 80027810:    e8 7b 3c 06 00           call   8008b490 _KeGetCurrentIrql@0
> 80027815:    25 ff 00 00 00           and    $0xff,%eax
> 8002781a:    50                       push   %eax
> 8002781b:    68 8d 03 00 00           push   $0x38d
> 80027820:    68 70 13 0b 80           push   $0x800b1370
> 80027825:    68 7c 13 0b 80           push   $0x800b137c
> 8002782a:    e8 21 b7 ff ff           call   80022f50 <_DbgPrint>
> ...
>
> The first call to KeGetCurrentIrql returns an irql which is higher than
> APC level. The second call returns PASSIVE_LEVEL. This can't occur
> because there is no function which  raise or lower the irql. It may be
> possible , that a task switch occur before and after the first call to
> KeGetCurrentIrql and which has set the irql to a wrong value.
> Hartmut

Was it in idle? I left my system running, just idling. Come back ~12 hours later
and find it in a blue state of mind.

BTW, Csrss eats 3 to 5% of the system just setting there.

James

[Mike Nordell]

Hartmut Birr wrote:
> I get weird crashs if I set OARCH to pentium4. Looking to te PAGED_CODE
> macro in ExMapHandleToPointer:

I suggest changing the macro to something like:

#define PAGED_CODE() \
{ const KIRQL irql = KeGetKurrentIrql(); /* use 'irql' for the debug print
*/ }

If not, it's simply impossible to get correct and intended functionality,
should preemtion occur.

/Mike

[Thomas Weidenmueller]

Mike Nordell wrote:
> Hartmut Birr wrote:
>
> If not, it's simply impossible to get correct and intended functionality,
> should preemtion occur.

I very much doubt the irql should change at all...

Best Regards,
Thomas

[Gunnar Dalsnes]

Thomas Weidenmueller wrote:
> Mike Nordell wrote:
> > Hartmut Birr wrote:
> >
> > If not, it's simply impossible to get correct and intended functionality,
> > should preemtion occur.

Irql must obviously stay the same no matter if we were preempted and/or 
taskswitched a trillion times. The case here is probably a bug in the 
task switcher, where it "restores" the thread at a irql different from 
what was current when it was "suspended", and after 11 hours(!) this bug 
just happends to materialize in-between two related KeGetKurrentIrql 
calls. It doesnt sound very likely, does it... Still, i cant think of 
anything else that may cause this behaviour.
> >
>
> I very much doubt the irql should change at all...

Youre right
> Best Regards,
> Thomas
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[James Tabor]

WOOOO!
Thomas Weidenmueller wrote:
> Mike Nordell wrote:
> > Hartmut Birr wrote:
> >
> > If not, it's simply impossible to get correct and intended functionality,
> > should preemtion occur.
>
> I very much doubt the irql should change at all...
>
> Best Regards,
> Thomas

It did not click in my pee brain, "Preemption"? How could it preempt inside
kernel space? I thought atm that was imposable.

8^o,
James

[Alex Ionescu]

James Tabor wrote:
> WOOOO!
> Thomas Weidenmueller wrote:
> > Mike Nordell wrote:
> > > Hartmut Birr wrote:
> > >
> > > If not, it's simply impossible to get correct and intended 
> > > functionality,
> > > should preemtion occur.
> >
> > I very much doubt the irql should change at all...
> >
> > Best Regards,
> > Thomas
>
> It did not click in my pee brain, "Preemption"? How could it preempt 
> inside
> kernel space? I thought atm that was imposable.

Yeah, we don't really preempt on UP as far as I know with the current 
scheduler. I think this only happens on MP, and I agree that the IRQL 
probably doesn't get restored properly. Hopefully it'll work fine in my 
scheduler...I had a similar problem but I found the bug and fixed it.

Best regards,
Alex Ionescu