Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

How can windbg know all the function arguments in the stack in x64? Is it realiable?

henrik_meidahenrik_meida Member Posts: 102
edited November 15 in NTDEV

Hi,

Considering that in x64, the first arguments are passed in registers, and therefore when i call another function inside that function, the previous arguments should be gone at that point (right?), so how can windbg tell me the arguments that is passed to every function when i use K and print the function frames that i have the private pdb symbols?

Basically i want to know if these function arguments that windbg prints in x64 are **100% **reliable or not?

I am asking this because i have a crash dump (x64) that for example has this sequence of calls : f1(myVar) -> f2(myVar)
But the thing is that windbg is giving me some random junk for myVar* in f2, but in f1 it is correct, and this varriable is not changed inside any of them, and since its x64, therefore the variable is also inside rcx so it cant be because of overflow either..

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470
    via Email
    Those register values have to be preserved on the stack/restored from the
    stack on a function call. The core debugger engine has gotten better at
    correlating stack/register/local var values, or at least that is my
    impression.

    Mark Roddy
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,163

    Basically i want to know if these function arguments that windbg prints in x64 are **100% **reliable or not?

    No, of course not. The debugger is never 100% reliable. It's always making educated guesses.

    The Microsoft x64 calling sequence requires that the function allocate enough stack space to save its registers, and most C++ routines will do so, but many low-level routines do not. It does a good job, but not a perfect job.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • henrik_meidahenrik_meida Member Posts: 102
    edited November 16

    @Mark_Roddy said:
    Those register values have to be preserved on the stack/restored from the
    stack on a function call. The core debugger engine has gotten better at
    correlating stack/register/local var values, or at least that is my
    impression.

    Mark Roddy

    @Tim_Roberts said:

    Basically i want to know if these function arguments that windbg prints in x64 are **100% **reliable or not?

    No, of course not. The debugger is never 100% reliable. It's always making educated guesses.

    The Microsoft x64 calling sequence requires that the function allocate enough stack space to save its registers, and most C++ routines will do so, but many low-level routines do not. It does a good job, but not a perfect job.

    I just checked the dump, and in fact windbg was printing the passed arguments to functions based on values pushed to stack before that function is called, therefore it was printing junk for my own local function call arguments, but in case of functions that were called by windows kernel (such as callbacks), the values were correct because these were passed arguments on the stack (assuming they are using stdcall convention)
    My question is why would windbg so naively assume that even in x64 the arguments are passed on the stack, even tho on most compilers are not? Shouldn't they at least print a warning when they print these function arguments on x64? because this in fact may confuse a lot of people thinking they have some sort of stack corruption, when they have not!

    Again i checked the stack, and windbg was basically just printing random values before the return address push of a function, assuming they are its arguments!! Why?!

  • henrik_meidahenrik_meida Member Posts: 102

    Side note: i also checked the disassembly to make sure the arguments are not passed on stack, and they were not, they were passed in rcx, rdx, etc.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470
    via Email
    Optimization can defeat windbg's efforts to track local vars correctly, so
    if you need all local vars in all stack frames you need to use debug
    components. That has always been true, however in my experience, windbg has
    become pretty good at tracking local vars in release (optimized)
    components, not perfect, but pretty good.

    The debugger understands the registry usage conventions for x64.
    Optimization can mess with that understanding.

    Mark Roddy
  • MBond2MBond2 Member Posts: 389

    In my experience, debug builds generally are very easy to debug and with release (optimized) builds your mileage will vary. And vary by a lot. A common technique is to look for the values of parameters or locals that are optimized away is to look on other levels of the stack as often these values that get carried only in registers at one level, come from values actually stored in real memory on another level

    It should be noted that x64 actually makes this problem vastly easier for the debugger versus x86

  • Ernie_CoskreyErnie_Coskrey Member Posts: 20

    We've had pretty good luck using Code Machine's debug extension dll (https://codemachine.com/downloads/cmkd.html) - it has a "!stack" command that can often find the parameters even when they're passed in registers.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online