print input parameter values

[George]

Hello everyone,

Suppose I am executing in a function, how to print values for input
parameters (binary memory value is ok) using WinDbg?

(suppose I am executing in a system API, and I do not know the exact input
parameter name in source code?)

thanks in advance,
George

[Ivan Brugiolo [MSFT]]

Unless there are symbols with type information, even the raw binary dump
is moslty an educated guesswork exercise .
For any given architecture and for each calling convention of the
architecture
the parameters may be in registers, in registers and stack, in the stack,
etc, etc.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message
news:E792AC80-28DD-4E21...@microsoft.com...

[George]

Thanks Ivan,

I have tried the dv command from WinDbg, is it the correct solution?

regards,
George

[Ivan Brugiolo [MSFT]]

Under the assumption that you have symbols with type information,
and that you are at the right place in the progue of a fuction,
then `dv /V` is the best you can get from the debugger.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message

news:8DEF878A-E420-4759...@microsoft.com...

[George]

Thanks Ivan,

"in the progue of a fuction" -- do you mean in the execution of a function?

regards,
George

[Ivan Brugiolo [MSFT]]

I ment to write `In the prologue of the function`.
If you are not in the correct place, you may get things such as
register reuse, local variable storage aliasing, and stack alignments
that may greately confuse you if you just trust `dv /V`.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message

news:4FCA3570-8D9D-487C...@microsoft.com...

[George]

Thanks Ivan!

I think "In the prologue of the function" is the same as in the execution
(body) of a function, correct?

regards,
George

[Ivan Brugiolo [MSFT]]

Not really.
The prologue of a function is a well-defined concept only for x64 and ia64,
and, it is even expressed in the function descriptor.
On average, on x64, it ends where the `rsp` register is decremented.
For x86, I'd say that the prologue is over after `mush ebp/mov ebp,esp`,
but, there are so many function and optimizations that the statement
is inherently imprecise and undefined at best.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message

news:93F77552-E944-41A1...@microsoft.com...

[George]

Thanks for clarifies this, Ivan!

Could I understand prologue means EBP/ESP is properly set in the function
being called?

regards,
George

[Ivan Brugiolo [MSFT]]

That is true for x86, and for function that do use a frame pointer.
Not true in general, given the aggressiveness of certain compiler
optimizations.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message

news:7C746A45-56C0-4EBD...@microsoft.com...

[George]

Thanks Ivan,

Great reply! A further question, when dv command will not work in your
experience? In my current debugging, it works fine.

regards,
George

[Ivan Brugiolo [MSFT]]

On x64, in code compiled without register homing.
On x86, in any sufficiently complex and optimized code.
On ia64 retail bits, it almost always never work.

If you debug checked un-optimized code on x86, then
you are in the best case scenario.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message

news:3ABB8151-625A-43EC...@microsoft.com...

[George]

Thanks Ivan,

1.

I am happy to learn from you about this. I am using x64. But I am not sure
what do you mean "compiled without register homing", is it a compile option?

2.

If dv command has some limitation on x64, what is your preferred solution to
display parameter/local variable/register values in Windbg?

regards,
George

[Ivan Brugiolo [MSFT]]

#1
cl.exe /homeparams
from the help: Force parameters passed in registers to be written to the
stack.
Please search on groups.google.com for
`ivan brugiolo x64 MASM register homing` to learn more.

#2
`dv /V` has limitations in all architectures.
Once upon in time, I learned to debug optimized IA64, and,
recovering the `locals` from the 128+128+64+special registers
was everyday job, and, the few x64 registers do not scare me anymore.
When `dv /V` gives suspicious output, I read the disassembly

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"George" <Geo...@discussions.microsoft.com> wrote in message

news:47D2F8AA-0BDE-4F2D...@microsoft.com...

[George]

Thanks Ivan,

1.

Do you know where to set homeparams from Visual Studio 2008 IDE? I have
tried hard but can not find out. Most time, I prefer to use IDE other than
command line. :-)

2.

From your reply, the issues of dv /V is it will put local variables into
register other than on stack? Sorry my English is not very good, please feel
free to correct me if I am wrong. :-)

regards,
George