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