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]
Related
Sometimes when using the data viewer in debug mode in Visual Studio 2010 (C++), I cannot see the data. I can see the data of many other variables, but not the one shown below. The element below is an array. How do I get rid of the "(error)" messages and see the data?
Update: I wrote a member function called "view". If I jump into the function call, the debugger works fine and I can see all the class variables. So maybe this is an issue with the debugger following pointers.
Is your object "test" one of standard STL class (vector, set, etc..)?
If yes, usually you should get also size in debugger tooltip - and this looks like corrupted autoexp.dat file.
If you did some modification in autoexp.dat, then try to revert it back and check if this helps.
So when i want to move forward i can use f10/f11 but can i move to previous state? Not just previous position because if i just move or set cursor to previos position this not recovers values of variables. This is not possible?
You can do it, if you are willing to use a different debugger.
GDB supports this feature. Using GDB with MS VS is left as an exercise for the reader & Google, but here are a few helpful links:
How can I use GDB from inside Visual Studio C++ (Express) to debug my GCC Makefile projects?
https://visualstudiogallery.msdn.microsoft.com/54B953C9-FD8A-4D6F-8C98-D0A1A786CBBE
or perhaps this, but it's pricy http://visualgdb.com/
Note: I am assuming that your code is Windows specific. If not, and you really want this feature, set up a Linux VM and use GCC / GCB (and look into the DDD front end - which lets you examine linked structures visually )
There is no such feature, if there was then it would be listed in docs (and probably available to enterprise version only):
http://msdn.microsoft.com/en-us/library/y740d9d3.aspx
also imagine how much memory this would require, debugger would have to snapshot application state on each debugger step. The closes thing to what you want is:
Microsoft Time Travel Tracing Diagnostic Tool
I have never used it, also it is not a debugger addon.
OK, so there are numerous questions around, asking for a "Visual Studio equivalent on Linux" or a variation of this question. (here, here, here, ...)
I would like to focus on one aspect and ask how the debugging workflow possibly differs on different systems, specifically the full-integrated-IDE approach used by Visual Studio (like) systems and a possibly more "separate" toolchain oriented approach.
To this end, let me present what I consider a short description of the "Visual Studio Debugging Workflow":
Given an existing project
I open up the project (one single step from a user perspective)
I navigate to the code I want to debug (possibly by searching of my project files, which is simply done by opening the Find in Files dialog box.)
I put a breakpoint at line (a), simply by putting the cursor on the line and hitting F9
I put a "tracepoint" at line (b), by adding a breakpoint there and then changing the breakpoint properties so that the debugger doesn't stop, but instead traces the value of a local variable.
I hit F5, which automatically compiles my executable, starts it under the debugger and then I wait until the prg stops at (a), meanwhile monitoring the trace window for output of (b)
When the debugger finally stops at (a), my screen automatically shows me the following information in (one-time preconfigured windows) side-by-side at the same time:
Current call stack
values of the most recently changed local variables
loaded modules (DLLs)
a list of all active breakpoints with their locations
a watch window with the last watch expressions I entered
A memory window to examine raw memory contents
a small window displaying current register values
Plus/minus some features, this is what I would expect under Eclipse/CDT under Linux also.
How would this workflow and presented information be retrieved when developing with VIM, Emacs, gdb/DDD and the likes?
This question isn't really about if some tool has one feature or not, it's about seeing that development/debugging work is using a combination of features and having a multitude of options available at your fingertips and how you access this information when not using a fully integrated IDE.
I think your answer isn't just about which software you use, but also what methodology you use. I use Emacs and depends on TDD for most of my debugging. When I see something fail, I usually write tests filling in the gap which I (obviously) have missed, and checks every expectation that way. So it goes far between each time I use the debugger.
When I do run into problems I have several options. In some cases I use valgrind first, it can tell me if there is some memory related problems right away, eliminating the need for the debugger. It will point straight to the line where i overwrite or delete memory that should be left alone. If I suspect a race condition valgrind is pretty good at that to.
When I use the debugger I often use it right in emacs, through GUD mode. It will give me a view with stack, local variables, the source code, breakpoints and a window where I can command the debugger. It usually involves setting a couple of breakpoints, watching some memory or some evaluation, and stepping through the code. It is pretty much like using the debugger in an IDE. The GDB debugger is a powerful beast, but my problems has never been large enough to need to invoke its power.
When I'm debugging C++ mixed (managed/unmanaged) projects in Visual Studio 2005, I often get weird data from the debug watches, like below :
(btw, the variable i_processName is a const std::string & )
alt text http://img175.imageshack.us/img175/3561/43419953av1.jpg
Note that the variable actually holds valid data - if i print it to stdout, the printed string is just fine, thanks for asking.
The simpler types of data (e.g. ints) (usually?) get their correct values shown.
Did this ever happen to you too?
This is a major PITA when debugging, so ... any ideas on how to make the watches show the correct data, or what's causing this?
Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).
Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.
Yes, i see this problem in my debuger, in my case its connected to Unicode vs NonUnicode.
Looks like your debugging symbols are incorrect.
Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.
If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.
A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?
It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.
One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.
I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.
This is a bug that has been in the Visual Studio debugger since forever and still occurs in Visual Studio 2019.
It is random.
Sometimes making a code change and recompiling resolves the problem, and sometimes it doesn't.
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.