Stack Text arguments

WINDBG
1

Hi All,

I am analyzing the crash dump. I got the analysis using !analyze -v. I am confused about the stack text arguments.

e.g. eeb366ec f86152d9 82142358 821c7618 82142358 usbhub!USBH_PassIrp+0x18
(First ARG) (second) (third)
The first two fields are address. The next 3 fields are the function arguments.

Is it correct? If the function has only 2 arguments, will the last field 00000000 or the first will be 00000000?

Thanks,
Harsha

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

2

Harsha Inamdar wrote:

Hi All,

I am analyzing the crash dump. I got the analysis using !analyze -v. I
am confused about the stack text arguments.

e.g.
eeb366ec f86152d9 82142358 821c7618 82142358 usbhub!USBH_PassIrp+0x18
(First ARG) (second) (third)
The first two fields are address. The next 3 fields are the function
arguments.

Is it correct? If the function has only 2 arguments, will the last
field 00000000 or the first will be 00000000?

The first number, as I’m sure you know, is the stack address where it
got this information. The second number is the code address where this
function will return.

Windbg has no idea at all about how many parameters were passed or
expected. ALL it is doing is dumping the first four dwords of memory at
the given stack address. If the function is a standard stdcall
function, you will see the first three arguments there. If the only one
argument was pushed, then the other two dwords will be whatever was on
the stack at that point. It’s probably local stack data from the
calling function.

If the function is a fastcall function (IofCallDriver or
IofCompleteRequest, for example), then the first two parameters are
passed in registers, and there may be nothing meaningful at all in the
stack trace.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

You can use kp or kP to have window do a stack trace and display parameters according to symbol info. Note however that symbol info is often wrong for optimized code.

From: xxxxx@lists.osr.com on behalf of Tim Roberts
Sent: Tue 1/24/2006 9:53 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Stack Text arguments

Harsha Inamdar wrote:

Hi All,

I am analyzing the crash dump. I got the analysis using !analyze -v. I
am confused about the stack text arguments.

e.g.
eeb366ec f86152d9 82142358 821c7618 82142358 usbhub!USBH_PassIrp+0x18
(First ARG) (second) (third)
The first two fields are address. The next 3 fields are the function
arguments.

Is it correct? If the function has only 2 arguments, will the last
field 00000000 or the first will be 00000000?

The first number, as I’m sure you know, is the stack address where it
got this information. The second number is the code address where this
function will return.

Windbg has no idea at all about how many parameters were passed or
expected. ALL it is doing is dumping the first four dwords of memory at
the given stack address. If the function is a standard stdcall
function, you will see the first three arguments there. If the only one
argument was pushed, then the other two dwords will be whatever was on
the stack at that point. It’s probably local stack data from the
calling function.

If the function is a fastcall function (IofCallDriver or
IofCompleteRequest, for example), then the first two parameters are
passed in registers, and there may be nothing meaningful at all in the
stack trace.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com