James Tabor wrote:
Hi!
Look at the cmd line options! It did display the debug printout for the devices.
Cool, Kick A$$, Rosxor! Alex!
James
Hi James,
Let's do a bit of bugcheck debugging. First of all, always take note of
the first parameter when hitting a 0x0000001E. In thise case, it's
0x80000003. In case you don't know, this is STATUS_BREAKPOINT, which
means the code hit an int3. Usually this means an assertion, not an
actual bug.
The next step is to see where this int3 came from. We have the answer
from two places: first, the stack frame, which shows 81022F95, and the
actual 2nd paramter, which shows 81022F94. The off-by-one difference is
caused by the fact the stack shows the line *after* the int3.
Now all we need to do is run "raddr2line module 81022f94". I don't know
what driver is loaded at 0x81022F94, and it actually looks like dynamic
code, but this should put you on the right road.
*** Fatal System Error: 0x0000001e
(0x80000003,0x81022F94,0x00000000,0x00000000)
<ntoskrnl.exe:2891 (ntoskrnl/ke/bug.c:1078 (KeBugCheckEx))>
<ntoskrnl.exe:86b66 (ntoskrnl/ke/i386/exp.c:995 (KiDispatchException))>
<ntoskrnl.exe:8913b (ntoskrnl/ke/i386/trap.s:681 (CommonDispatchException))>
<81022F95>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS