[ros-dev] Multiple problems with HEAD

[Alex Ionescu]

Hartmut Birr wrote:

>Ge van Geldorp wrote:
>
>  
>
>>1st problem: when booting rev 14873 (DBG := 1, KDBG := 0) it crashes with:
>>
>>DriverBase for \SystemRoot\system32\drivers\fs_rec.sys: 9cf7c000
>>(io/file.c:898) Status :0
>>(io/file.c:898) Status :0
>>(io/file.c:898) Status :0
>>DriverBase for \SystemRoot\system32\drivers\beep.sys: 9cf8b000
>>(io/file.c:898) Status :0
>>Assertion NewRefCount >= 0 failed at ob/object.c:1150
>>KeBugCheckWithTf at ke/catch.c:217
>>A problem has been detected and ReactOS has been shut down to prevent damage
>>to your computer.
>> 
>>
>>    
>>
>The problem is in IoSecondStageCompletion. Sometimes Irp->UserEvent
>points to Fileobject->Event. Dereferencing such an event object crashs ros.
>  
>
That shouldn't be happening... there must be a problem in the driver 
that does this or something, for nothing I've read mentions this.

>  
>
>>The problem seems to be caused by the following file: ntoskrnl.exe
>>
>>KMODE_EXCEPTION_NOT_HANDLED 
>>Technical information:
>>
>>*** STOP: 0x0000001E (0x80000003,0x800057a4,0x8005d08b,0x8071c9ec)
>>
>>***    ntoskrnl.exe - Address 0x800057a4 base at 0x80000000, DateStamp 0x0
>>
>>Breakpoint Exception: 3(0)
>>Processor: 0 CS:EIP 8:800057a4 <ntoskrnl.exe: 57a4>
>>cr2 8ccfc000 cr3 27000 Proc: 8053fcf8 Pid: 4 <System> Thrd: 805407f0 Tid: 0
>>DS 10 ES 10 FS 30 GS 10
>>EAX: 00000036   EBX: 8004515d   ECX: 00000000
>>EDX: 000003f8   EBP: 800e47a4   ESI: 800e4a84   ESP: 800e4730
>>EDI: 800e49f4   EFLAGS: 00200286 kESP 800e4730 kernel stack base 800e3000
>>Frames:
>><ntoskrnl.exe: 72a9f>
>><ntoskrnl.exe: 45f2a>
>><ntoskrnl.exe: 456e1>
>><vfatfs.sys: 2d00>
>><vfatfs.sys: d1de>
>><vfatfs.sys: d3ee>
>><ntoskrnl.exe: 45158>
>><ntoskrnl.exe: 40487>
>><ntoskrnl.exe: 414dd>
>><ntoskrnl.exe: 3602>
>><7D83F045>
>><ntoskrnl.exe: 3e6c0>
>><ntoskrnl.exe: 3602>
>><EC83FC45>
>><ntoskrnl.exe: 3de8e>
>><800A48CE>
>><800A21D4>
>><ntoskrnl.exe: 10004>
>><800A07AA>
>><ntoskrnl.exe: 104b>
>>
>>2nd problem: the crash info is only written to the debug log and not shown
>>as a BSOD.
>> 
>>
>>    
>>
>It is result from Alex' debugger rewrite, currently I cannot find the
>real problem.
>  
>
You mean if you only have logging to the debug log (and not screen), you 
don't see the BSOD? I can fix that easily...let me know if that's the 
problem.

>  
>
>>3rd problem: the stack trace only shows addresses, not source file/line as
>>it should for a DBG build
>> 
>>
>>    
>>
>It may be fixed by the attached patch, but sometimes ros doesn't load
>the symbol files for ntoskrnl and hal. I'm not sure, If it is a problem
>of the debugger rewrite or a problem from freeldr.
>  
>
It's an old problem... sometimes the crash is too early for the symbols 
to be loaded... I've seen this problem before the rewrite.

>  
>
>>4th problem: booting with /DEBUGPORT=GDB results in a kernel stack fault
>>very early in the boot process.
>> 
>>
>>    
>>
>One init function is called twice. The first call should only
>initialized boch and comX debug, the later call should initialized all
>other debug channels.
>
>5th problem: After fixing the 1st problem, there is no keyboard responce
>within usetup.
>  
>
I ran into this as well which is why I haven't had the time to find a 
good fix.

>6th problem: The second stage setup hangs after starting csrss. csrss
>reports an error.
>
>There are many problems from the io rewrite. We should revert Alex'
>changes and implement it again step by step.
>  
>
The problems are from the multiple drivers and places in the kernel that 
do things the way they shouldn't be done because they depended on broken 
functionality. I'll check my code again to make sure I didn't leave in a 
bug, but it's really annoying to fix something and have other stuff 
break because it depended on it.

>- Hartmut
>
>
>  
>
Best regards,
Alex Ionescu