Case Study: How to Find the Stack Overflow For Threads Running In Kernel Space

Problem Definition

The customer is experiencing intermittent bugchecks on some of the Citrix MetaFrame XP servers.

Environment

Citrix:

Product - MetaFrame XP, Feature Release 3/Service Pack 3
Hotfixes - 078, 082, 100, 119 & 126
Language –English
Clients – 32-bit Windows 6.x, Wyse 2310,2315 with 4.x client built into the firmware

Microsoft:

OS - Windows 2000/2003
Language - English

Troubleshooting Methodology

Find out following details before you start analyzing the systems dumps. All of this information is very important for the dump analysis.

Any recent updates to the systems.
Citrix Related: Did they experience the fatal error after applying any new Citrix patches, hotfixes, or Service Packs? Obtain information about other installed patches, hotfixes and service packs on the faulting server.
Microsoft Related: Did they experience the fatal error after applying any Microsoft related patches? Obtain information about other installed patches, hotfixes and service packs on the faulting server.
Find out information about third party installed applications, such as virus scanners, and any other background tools running such as UPHClean. Find out about any recent changes to these applications.
Find out whether the systems are configured to catch a complete system dump. If not, have the problem server configured to capture complete memory dumps.

Note: Why do we ask for a complete memory dump? Complete memory dumps provide the state of the system that includes both user space and kennel space at the time of fault. Complete memory dumps help analyze and show the faulting components both from the user space and kernel space to complete an accurate and quick turnaround of the issue.
Refer to Overview of memory dump file options for Windows 2000, for Windows XP, and for Windows Server 2003 for more information.
Note: The complete memory dump option is not available on computers with 2 gigabytes (GB) or more of RAM. For additional information, refer to Complete memory dumps not available on computers with 2 or more gigabytes of RAM.

Analyzing the system dump. Assumptions/requirements:
Basic knowledge of using debugging tools from Microsoft, such as windbg.exe.
You need the latest version of the windbg tool from Microsoft installed on the box. The windg tool is available from Microsoft.
Symbols for the third party applications if needed (such as Citrix MetaFrame XP).
Public symbols for Microsoft OS. They can be sourced from the following link and it also provides information on how to configure the windbg to access these public symbols. Debugging Tools and Symbols: Getting Started

Detailed analysis steps:

Load the system dump using the windbg tool. Once the dump loads successfully without any problem issue the !analyze –v command. This command dumps these details about the bug/fault in the following order:

i. General information about the bug check details

ii. State of the microprocessor registers at the time of fault

iii. Stack trace of faulting thread

iv. Faulting module details

Generally I do not rely or use this information to come to the conclusion of the issue.

The above information provides general pointers, information, and lays the ground for the next course of actions to take. The stack trace suggests that a crashing thread is running through the Citrix module, vdtw30.dll, along with some Microsoft and third party related drivers/dlls. Now based on my experience of dumps analysis and the above information, I would like to see the complete stack trace of the faulting thread. So I issue the following command to dump and list all the function calls starting from the bottom of the stack to the top of the stack of faulting thread.

kv 100 - list all the top 0X100 function calls from the top of the stack trace.
Here is the output of the above command:

Now if you observer the above complete stack dump closely you will find, 75 function calls in the faulting thread, which definitely raises a red flag.

Most of the time when I unwind the faulting thread completely, I find around 10 to 25 function calls. In this situation, I go directly to the top of the stack and start looking closely at each function call and start verifying the parameters to the functions and if necessary unassemble suspicious functions to look more closely at what’s really going on with the passed parameter and local variable in the function body.
In this case we are not following that above route. We dump the stack one more time with a different command that provides the stack consumption of each function. This command is:
kf 100 – f switch to k causes the distance between adjacent frames to be displayed. This distance is the number of bytes separating the frames on the actual stack.
The stack appears as follows:

The Microsoft operating system defines/assigns 12k bytes of stack space to each thread running in the Kernel space and it’s enough to store local variables and parameters for functions.

Here is an explanation of the different parts of the function call of the stack.
A typical function call in stack appears as follows:

Total number of bytes consumed/used by the function from the stack space of thread.
EBP pointer of the function, it’s used as a reference pointer to access the local variable and parameters passed to the function.
Return address of the instruction in the function xxxPaintSwitchWindow() that called the function DrawSwitchWndHilite().
example:
b5f19790 a005c06a win32k!DrawSwitchWndHilite+0x1ba (FPO: [Non-Fpo]) (CONV: stdcall)
3c b5f197cc a005c155 win32k!xxxPaintSwitchWindow+0x16c (FPO: [Non-Fpo]) (CONV: stdcall)
a005c06a = win32k!xxxPaintSwitchWindow+0x16c
Module name, which can be exe, dll, or sys file.
Function name.
Offset of the next instruction from the start of the function that needs to be fetched to microprocessors accumulator (also know an ALU, Arithmetic logic unit), for decoding and execution.

Now we have enough information on what to do next. If we add all the bytes used/allocated by each function on the thread stack, we find that it exceeds or is almost equal to the 12k limit. Because we have hit this limit, there is no stack space left for any subsequent function calls and this condition led to the fatal error.

Now we need to identify and list all the function calls in this stack trace that are using very large amounts of stack space. Two of them are as follows:

The above two function calls are using the larger stack space. One function call belongs to Citrix module vdtw30.dll and the other one belongs to HP driver q57w2k.sys.

After isolating the Citrix function call, I verified the implementation for function, DrvTw1TextOut() and found one of the local variables in this function, an array to structure, consumed almost 4k of memory.

Resolution

Citrix allocated this array on the system pool and defined the pointer to this array as a local variable that held the address to this array. This implementation reduced the consumption of stack space by this function from 4k bytes to just 4 bytes at the cost of some performance. This made 4k bytes of free space on the thread stack space so that other functions can use this valuable resource.

Additional Information

Windbg Tool Help provides extensive help on how to use the debug tool and the different commands supported by it that help to analyze dumps and conduct live debugging.