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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev