Part 1: Introduction to the Debug Kernel

Procedures: Introduction

Change to directory CLASS\LABS\LAB09 2.

Execute OSPREY, see the failure, and the trap screen. At the failure, record CS:EIP from the trap screen.

CS _________ EIP _____________

At this point, it is too late to cause a dump. Dismiss the trap screen.

We will refer to the system on which the problem occurs at the Machine Under Test, or the MUT. The MUT is connected via a null modem cable to an adjacent machine, which we will call the debug terminal. Most of the debugging actions will occur from the debug terminal, on which we will run a public domain terminal emulation program, LOGICOMM. If you like LOGICOMM and intend to use it frequently, you should register it, which will also get you an improved version.

Let's use the debug kernel for the first time. First, we need to get its attention. The way to do this is to enter Control-C on the debug terminal, after starting LOGICOMM. The debug kernel defaults to settings
9600, N , 8, 1

Start LOGICOMM on the debug terminal, then type Control-C.

The default response of the debug kernel is the registers at whatever point OS/2 was interrupted by the Control-C. This is not generally very useful. We need to get control where we want it, not at a random place.

Enter the command VSF*

This tells the debug kernel that you want control on any interupt which may be Fatal to a thread. The 'F' is for fatal, the '*' is for 'any'.

Enter the command G (Go), so OS/2 can continue.

On the MUT, rerun OSPREY.

This time, you should get a group of lines on the debug terminal which tell you that a fatal failure has occurred.

Enter the command DG CS You will find that this is in ring 0.

Before we look at ring 0, let us find where ring 3 called ring 0, and also identify the API which was called.

Enter the command .R (the period is very significant!)

.R shows you the ring 3 registers, whereas R shows you the current ones.

CS=__________ EIP=_____________ Does this match the trap screen?

eax=00000000 ebx=0000405c ecx=00000000 edx=00000001 esi=00000000 edi=000016b0
eip=00001bc3 esp=000011e4 ebp=0000120e iopl=2 -- -- -- nv up ei pl zr na pe nc
cs=000f ss=001f ds=001f es=001f fs=150b gs=0000  cr2=00000000  cr3=001a7000
000f:00001bc3 0bc0           or      ax,ax

We already know this instruction did not trap; the trap is in ring 0.

If we unassemble prior to 000f:1bc3, we will find a far call.

...1BBE call ___________:0000

The instruction as hex data is _____ _____ _____ _____ _____

If you inquire about the descriptor by entering DG and the selector, You should see something similar to this
```
# DG 1xxx
1xxx  CallG32 Sel:Off=0148:0000550a     DPL=3 P  DWC=7
```

Write down CS ______ EIP__________ DPL________ DWC________

If you enter the LN command with the values of CS and EIP from the call gate, you will identify the API which is called via this gate.

We know how to find parameters on the ring 3 stack, DW SS:SP

We can also find them on the ring 0 stack, but at this point, the kernel has already manipulated some of the addresses, so there is not an exact match. We need to get control at the point of the call at 1BBE.

Enter the command GT which will GoThrough the trap.

[Back: Exercise 7: Looking at a Ring Transition]
[Next: Part 2: Some Techniques]