Debugging Windows NT kernel STOPs on RISC-based platforms

This article discusses the basic steps involved in reading and interpreting the kernel stack on RISC platforms, using the DEC Alpha AXP as a base example. The following basic areas are covered

• What you will see on the stack.
• Finding the trap frame and getting the stack before the exception.
• Tracing function call arguments.

It is assumed that the reader has a basic understanding of kernel debugging Windows NT on Intel-based systems, as that is used as a basis for comparison. Any debug commands listed should work in WINDBG as well as the KD debuggers (ALPHAKD, MIPSKD, PPCKD).

Part 1: The Windows NT stack on a RISC system

On an Intel-based system, a stack dump using the KB or KV command gives you a wealth of information. This is because of three things that are done in Intel assembly when a function call occurs:

• Before the call, all arguments are pushed onto the stack (with a few exceptions).
• During the call, the return address of the function making the call is pushed on the stack.
• After the call occurs, most functions push the base pointer (EBP) onto the stack.

These three steps allow the debugger to display a stack showing the first three arguments passed to each function, as well as other information (such as trap frames). On a RISC system, the frame pointers (equivalent to the EBP) are present as are the return addresses. However, arguments are passed in special argument registers and cannot be found on the stack. RISC systems will use the stack for more permanent storage of variables (as you will see later).

On MIPs-based and Dec Alpha-based systems, the arguments are passed in order, first to last, in registers labeled a0, a1, a2 and so on (referred to as the argument registers). There are 4 such registers on MIPs systems (a0 - a3) and 6 on an Alpha (a0 - a5). If there are more arguments than can fit in the aX registers, both types of systems use the temporary (t0 - t7) registers. On PPC systems, the arguments are passed in order, first to last, in the registers r3, r4, r5 - r31.

The following examples show an Intel system and an Alpha system stack (using the KB and KV command on the Intel system, the KB command only on the alpha):

NOTE: In the above stacks, the Param3 column was removed for readability.

The first two stacks are from a STOP 0xA on an Intel system. In the KB command output, the first two parameters passed to each function can be seen on the stack and you would normally see the third parameter as well. In the KV command, trap frames associated with the function call also show up.

The third stack is from a STOP 0x24 occurring on a DEC Alpha system. The frame pointers and the return addresses are all valid, however, the parameters, although they may appear to be valid addresses, are not necessarily arguments. Generally, the parameters are values that are pushed on the stack by the functions themselves.

Part 2: Finding the trap frame on a Windows NT RISC system

On a RISC system, the KV command will not show the trap frame as it will on an Intel system; more work is required to find the trap frame. In most cases, the frame pointer from one of the exception handling routines will be used as a trap frame and will need to identify the correct function. If that is not possible, you might also be able to identify a function which passed the trap frame as an argument.

Here is an example from the STOP 0x24 stack listed above:

First, recognize where the exception handling code starts and ends. This indicates what portion of the stack is exception handling code and where the trap occurred. In the above stack, the first exception handling routine is NT!KiMemoryManagementException, the rest of the stack is all exception code. This means that the actual line which caused the trap is NT!ExFreePool+0x270.

Next, walk through the code for each function, starting with KiMemoryManagementException until you find one that deals with the trap frame. There are two ways in this stack - first the FramePtr of KiMemoryManagementException should point to the trap frame. Additionally, the trap frame is passed to KiDispatchException as its third parameter.

Doing a !Trap on the FramePointer for KiMemoryManagementException shows the following:

Part 3: Tracing the function call arguments

Despite the fact that the arguments are not pushed on the stack on a RISC system, it is still possible to trace the arguments as they are passed from function to function; although it will require some knowledge of the assembly language used to do so. The only thing that makes it possible is the fact that in RISC assembly, most function calls initially save off several of the commonly used registers on to more permanent storage locations on the stack. This means that it can be possible to trace the arguments by performing the following steps:

1. Disassemble each function on the stack in two places, at the very beginning and before the call to the next function.
2. Look at what is being put into the argument registers before each function call, and what happens to both the argument registers and any other registers in use after the function call.

In most cases, you will find one of two things; either the argument registers themselves are pushed on the stack at the beginning of the call, or the registers whose values where loaded on to the argument registers were pushed on the stack.

Here is an example from an Alpha dump file. The portion of the stack you wish to trace is:

Starting with the first function, BinarySearchIndex, the code shows 5 parameters, which means that on an Alpha, registers a0 through a4 will be used to pass them.

Now disassemble the function which called BinarySearchIndex, right before the return address. This will reveal where the values in the a0 through a4 registers came from:

The above assembly instructions would be read as follows:

1. bis zero,s1,a1: bis is the mnemonic for a logical or, zero is a reference to a special register on the Alpha that always holds the value zero. This instruction is a fast copy from one register to another, in this case s1 to a1. The other three bis instructions accomplish the same purpose with different registers.
2. ldl a0,0x54(sp): ldl is the mnemonic for load long, which loads the long (dword) value from the memory address in operand 2 into the register in operand 1. 0x54(sp) is the Alpha equivalent of the Intel instruction dword ptr [ebp+54].
3. bsr ra,BinarySearchindex: bsr is a branch subroutine command, this is effectively the same as a call on an Intel system.

Based on the above assembly, the following values are being placed in argument registers:

Now disassemble the beginning of BinarySearchIndex to see what is done with all of the above registers:
In the above code, you are saving off a number of the registers using the instructions stq (store quadword) and stl (store longword)(dword). These instructions work similarly to load longword(ldl) but in reverse: the value in the register is written out to the memory address specified by the memory location. In the first seven instructions, the s0 through s5 registers are written out to various locations on the stack, and later a0 is also written out on to the stack. You now know the following:

At the beginning of a function like this, the sp is equal to the FramePtr value given in the stack dump for this function(f16c7550), you can use that to dump out the values for the following arguments:
To verify that you have found the correct values, check the function code to determine the variable types, and use that information to determine if you have the correct values. This method will work for tracing the values of most arguments passed from function to function, although occasionally you might have to follow a variable through a couple of functions before you find it pushed out onto the stack in an identifiable location.