As of late I have been working extensively with struct and classes in visual studio.Most of them have a lot of values witch makes them hard to track in the watch windows while debugging because the watch windows and the floating watch windows ( the one you can pin , dont know precise term ) always show the memory address which obscures the view of the values. Is there a way to make it so that the watch windows only show the values and not memory addresses
Write the custom natvis would be a workaround.
But if the debugger knows the type of the memory location, I think it can display the value.
Reference:
Is it possible to watch the value of a memory location using the Visual Studio Debugger's Watch window?
In addition, using format specifiers in watch window would be helpful for you to visit the value format:
https://msdn.microsoft.com/en-us/library/75w45ekt.aspx
Related
I need to debug a complex GC written in C++ and there is a lot of aliasing for variables inside the code which makes tracking the value of a specific variable quite difficult. Usually I do this using data breakpoints, but obviously the address changes every debug session and I need to add a breakpoint where the variable is created, get its address, remove the old breakpoint, add the new one, etc. If I multiply this process for several variables it becomes annoying and also time consuming.
Is it possible to add a data breakpoint programmatically?
I've found this answer Programmatic data breakpoint in Visual Studio 2010, but it's quite old and I hope there is better support for this.
I'm new to c++ debugging and LLDB. I'm using VSCode with its c++ adapter, LLDB as the debugger, and bazel as the build system. My application deals with manipulating images. The application runs quickly but debugging it is very slow. That's because once I've loaded the images into memory, it takes about 20 seconds to a minute to step through each line. My assumption is that the raw images are too much for the debugger. If I use a small image, then I'm able to step through the code quickly inside the debugger
My question is: is there a way to tell the debugger to ignore the image loaded variables? Or perhaps to lazy-load the image variable data? I'm more interested in the other variables such as the matrices.
The underlying debugger, lldb, doesn't fetch any variables unless explicitly asked. It's always the UI that requests variable values.
In Xcode, if you close the Locals View, Xcode won't ask lldb to fetch variables. That does speed up stepping in frames with big local variables.
Then if you need to keep an eye on one or two of the variables while stepping you can use tooltips or the debugger console to print them on demand. You can also set up target stop-hooks in the lldb Console and use them to auto-print the variables you are tracking.
Some UI's also separate the "Locals" view from the "Watched Expression" view, so you can close the former and put the variables you need to see in the latter.
I don't know if VSCode allows you to close the Locals view, but if it does that might be a way to handle this problem.
I'm using visual studio for kernel debugging. Yes, I know all the tutorials say to use WinDbg, but visual studio is actually spectacular now for Kernel debugging. It's a more recent development.
When I have a pointer in the watch window, assuming it is an array, I would like to see multiple items in its list at once as a drop down. Normally in Visual Studio you would add ",AMOUNT" after the pointer to get multiple items, but this does not work when in kernel debugging mode.
Is this option available?
[Edit] As requested, I have attached an example image. In the watch window I have included multiple attempts to access the data in the "ProcessPath" variable.
During Kernel Mode Debugging, Watch window appears to work through WinDBG expression evaluator. That is, it works pretty much the same as WinDBG's Watch window. Therefore, your question is not really Visual Studio related, but rather it boils down to WinDBG's watch.
This is why ,amount syntax will result in showing amount as result - WinDBG treats , as "evaluate and discard", just like c++ does. This also explains why you prepend variables with $! which is WinDBG syntax for local variables.
While WinDBG supports quite a bit of c++ syntax, it will unfortunately fail to recognize c++ cast-to-array syntax such as (char(*)[4])$!ProcessPath (by the way, this works when debugging a usermode target in in VS debugger).
I have not found a single way to cast to array in WinDBG. It seems the only workaround available is to add specific elements of array to watch, like
ProcessPath[0]
ProcessPath[1]
ProcessPath[2]
ProcessPath[3]
ProcessPath[4]
ProcessPath[5]
ProcessPath[6]
ProcessPath[7]
ProcessPath[8]
In Visual Studio for my native C++ program I want to get a plot of some variables during debug. Mostly I use textual representation of the objects by editing autoexp.dat. But for some of the variables it is better to have a plot rather than having values in textual form.
So far I have used a function plot(const void* address,const char* type) , and called it from Immediate Window giving the variable address & the type, and internally casting it to proper type.
But this method has two disadvantages:
First is that, function overloading almost never works when calling a function from debugger (so I had to pass type as a second parameter), and the function call occasionally crashes, though it works perfectly when called from within code.
Second is, instead of writing a C++ function for plotting, I am interested to have a scripting language (like autoexp.dat or a VBScript) to give the internal data of the C++ object without writing any wrapper, so that I can use the script to store the data in a file or plot it.
In general I am interested to have something like Matlab or Ch IDE, where I can plot certain variable externally when the program is at a debug break.
Since VS 2005, Visual Studio has included Visualizers, which could almost have been designed specifically for your problem. MSDN explains the concept better than I can:
Visualizers are a new component of the
Visual Studio debugger user interface.
A visualizer creates a dialog box or
other interface to displays a variable
or object in a meaningful way that is
appropriate to its data type. For
example, an HTML visualizer interprets
an HTML string and displays the result
as it would appear in a browser
window, a bitmap visualizer interprets
a bitmap structure and displays the
graphic it represents, and so on. Some
visualizers allow you to edit as well
as view the data.
See here for a tutorial on how to write one.
You can plot variables in real-time charts with NetDebugPlot and NetDebugLog.
#include "NetDebugLog.h"
NetLog(myvar);
NetLog("test", myvar2);
As others have noted, I'm not sure exactly what do you wish to plot. I usually understand, when someone says he wants to "plot something", he usually means some array with numerical values.
If this is true in your case, Intel's Array Visualizer is maybe of some help. It can be downloaded freely, it integrates into visual studio, and you can use it in two ways: as a standalone application or while debugging ("while in some breakpoint") so you can plot array values "while program is running".
Could you use gnuplot for this? Spit out the data you want to plot as debug prints, and then while you're sitting at a breakpoint, copy it to an external file and run it through the plotter.
Why is the integrated vs debugger so... barely functional? I cannot see the contents of an object in memory. For example, I am working with bitmaps and I would like to see them in memory. Do I need a better debugger for this? If so I am interested in recommendations. Nothing too powerful like a disassembler, just the debugger.
I've never found it to be "barely functional". VS gives you disassembly by default when it can't find source, and it's pretty easy to get to the memory view. Debug-> Windows -> Memory. Type "this" into the Address: box to get the memory of your current object. To view a specific member type '&this->member_name'. It'll jump right to the first byte.
Debug | Windows | Memory | Memory1-4. Put the address of the block of memory you want to look at in the Address. It's probably the most difficult menu option you'll ever attempt to execute with your mouse (you'll see...).
In older versions of VS, if you wanted to look at the contents of a variable, you needed to determine the address of the variable, I usually used the watch window.
However, in newer versions, you often can just type in the name of the variable as the Address, just like you would in a watch window.
VS2005 has a "memory" tab that would give bytes of memory. I don't know exactly how to convince it to highlight blocks of hex for you to tell you which variables are which though.
Debug | Windows | Memory will let you look at any area of memory you want (subject to process/access limitations). This is in VS2005. Might be slightly different menu structure in other versions.
I don't know if it's any good, but a quick Google search for "debugger display memory as bitmap" turned up Bitmap Memory Debugger, which was designed to be used alongside another debugger such as Visual Studio or WinDbg.