I'm using windbg to debug an Windows executable. I want to know how I can see arguments passed to any function using WinDBG.
For example If I wanna know the parameters passed to function Kernel32!CreatefileA using Immunity Debugger or Olly debugger I will set a break point at entry point of Kernel32!CreatefileA.
Now in bottom right corner of debugger window i could see nicely what are the parameters are getting passed to Kernel32!CreatefileA by the program. Like this screen shot.
So my question is how how can I get a similar view of passed parameters using WinDBG.Is thre any way??
Is there any plugin which can represent the stack visually like olly or immunity??
Thanks in Advance
If you have private symbols, dv will show you locals and arguments. There is also a "Locals" window that can be opened with Alt+3 if you prefer to use the GUI.
If symbols are not available, it is not quite so easy. You can start with kv to see raw arguments and calling convention. Once you know the calling convention, you know where arguments are stored (stack and/or registers), and it is a matter of deciphering their layout in memory.
Related
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
I remember seeing somewhere that you can specify which dll to get the address of symbols so that one can use that variable in the watch window. I can't for the life of me remember where I saw this. The best that I can come up with is Format Specifiers in C++.
The reason I want this is so that I can see the visibility status of a window and MSVS keeps saying that identifier "IsWindowVisible" is undefined.
I was trying to use something like the following in the watch window:
::IsWindowVisible(m_hWnd),user32.dll
Using:
this->IsWindowVisible()
results in Function CWnd::IsWindowVisible has no address, possibly due to compiler optimizations. which is why I'm trying to use the win32 call. Ideas?
http://msdn.microsoft.com/en-nz/library/y2t7ahxk.aspx
Haven't tried it, but it seems to me that IsWindowVisible(m_hWnd) should work, or maybe IsWindowVisible(this->m_hWnd).
I'm using XCode to debug some code. Specifically, the code that I'm debugging exposes a float[][] as float**. I am unable to change this syntax, but I'm not certain it would help anyway.
After including a relevant breakpoint, I want to view the contents of the array in the Variables view of the debugger?
When I double-click on the variable in the list of Autos, I see that I can add a Summary Format which seems deceivingly like it might help, but for the life of me, I can't figure out how to use it!
In conclusion, how do I use the Variables View to see the contents of my array of arrays of this primitive type without resorting to typing commands directly to GDB (which, I believe, can also perform this function)?
As a continuation of this question and the subsequent answer, does anyone know how to have a job created using the Parallel Computing Toolbox (using createJob and createTask) access external toolboxes? Is there a configuration parameter I can specify when creating the function to specify toolboxes that should be loaded?
According to this section of the documentation, one way you can do this is to specify either the 'PathDependencies' property or the 'FileDependencies' property of the job object so that it points to the functions you need the job's workers to be able to use.
You should be able to point the way to the KbCheck function in PsychToolbox, along with any other functions or directories needed for KbCheck to work properly. It would look something like this:
obj = createJob('PathDependencies',{'path_to_KbCheck',...
'path_to_other_PTB_functions'});
A few comments, based on my work troubleshooting this:
It appears that there are inconsistencies with how well nested functions and anonymous functions work with the Parallel Computation toolkit. I was unable to get them to work, while others have been able to. (Also see here.) As such, I would recommend having each function stored in it's own file, and including those files using the PathDependencies or FileDependencies properties, as described by gnovice above.
It is very hard to troubleshoot the Parallel Computation toolkit, as everything happens outside your view. Use breakpoints liberally in your code, and the inspect command is your friend. Also note that if there is an error, task objects will contain an error parameter, which in turn will contain ErrorMessage string, and possibly the Error.causes MException object. Both of these were immensely useful in debugging.
When including Psychtoolbox, you need to do it as follows. First, create a jobStartup.m file with the following lines:
PTB_path = '/Users/eliezerk/Documents/MATLAB/Psychtoolbox3/';
addpath( PTB_path );
cd( PTB_path );
SetupPsychtoolbox;
However, since the Parallel Computation toolkit can't handle any graphics functionality, running SetupPsychtoolbox as-is will actually cause your thread to crash. To avoid this, you need to edit the PsychtoolboxPostInstallRoutine function, which is called at the very end of SetupPsychtoolbox. Specifically, you want to comment out the line AssertOpenGL (line 496, as of the time of this answer; this may change in future releases).
I want to be able to see the variable values while debugging a release application.
I have set the compiler option as Z7 and given a /DEBUG and /PDB: linker option. Now I have a pdb for the application.
With this set up I am able to put a break point (Windbg) inside the code and it hits properly. But I am not able to see the variable values.
The Locals window only shows the pointer value but I cant see the contents of the same. For instance if I have a pointer to a structure that has an int inside it, it just shows the value of the pointer. If I expand the same by clicking + in the tree, I see the variable name with the value as <Memory access error>
How should I make the release builds show the variable values?
Many times, you cannot see them because they don't exist. If you look at the optimized assembly code, you will find that many intermediate variables are completely removed in favor of performance. That is most likely what you're seeing, and the only way around it is to follow the disassembly and watch the right memory locations / registers.