I have a project in C#/.NET4 in which there are several nested loops within a method. Recently, I have noticed that I can't mouseover to inspect variable values within these loops. In fact, if I go to the immediate window and try to research the value manually, the compiler reports that the variable doesn't exist. When I mouseover nothing appears, but its only at certain parts of one method. If I look in other parts of the same code (I haven't been able to figure out what the difference between the parts is in terms of debugging) mouseover works fine. I have things as simple as:
for (int i = 0...)
{
XX Breakpoint is hit here XX
}
and I can't get the value of i! Is there some limitation of the VS2010 debugger that is a known issue where it would affect only certain sections of code? I deleted all my PDB files, completely rebuilt the files from scratch, and still it doesn't seem to know the variable exists. Any advice is greatly appreciated on this one.
Related
I am experiencing very strange behavior within VB6 IDE whenever the break point hits(Step Into, Out, Over), the class is closed and makes it impossible to debug. Then within window-Cascade i can re-open the class but again when break point hits, the class is closed. Can anyone help please.
Step execution does sometimes behave that way. The reason is that VB is event driven and when an event occurs, then the code behind that event will run, and your code that you are stepping through might NOT be the code that gets run, so things change and code runs while your PAUSED code is still on hold.
When I encounter that I overcome it by using debug.print to send my monitored variables' current values to the OUTPUT window, or if you need more elaborate capability, write a sub that sends the data to a local text file and then invoke that sub as needed, passing into the variables ( and labels ) that you want displayed.
Once debug.print or a logging routine is in place then run the code WITHOUT pauses or breaks. The debugging output will tell you what is happening, in what order etc, so no need to stop the code or risk altering the order of execution.
Be sure to include lots of 'context' data such as : 'Entering SUB_XYZ, Param values are A, B, C... NOW at line 99 in SUB XYZ.... NOW in TRUE side of IF TEST # 1....
Include time stamps on all outputs.
Put your tracing logic only around the suspected problem area, expand from there only as needed.
It's a pain, but it works.
I finally resolved this issue and problem was within Display settings within windows 10. Basically if I apply vertical settings by placing both screen vertically 2nd on top of first then this issue happens,if i apply horizontal settings then this issue does not happen.
problematic settings with vb
settings that does solves debugging issue. VB is so weird and old cannot cope with display settings
I keep getting this message Rect: identifier "posPt" is undefined hundreds of times in my debug output, yet, I can't find it in the code I'm debugging. So I tried to break whenever one of the following functions are called: _CrtDbgReport, _CrtDbgReportV, _CrtDbgReportW, and _CrtDbgReportWV, which I found by drilling down through the TRACE code. I also found _CrtDbgReportT and _CrtDbgReportTV as well, but they don't seem to have any linkage as I couldn't set a breakpoint on them.
In any case, it still wouldn't break, so either these are not being called and some other similar function is, or the debugger isn't getting all instances of the linkages.
So, my question is how do I find out where the output is being generated?
EDIT: The application is C++ native code with several DLLs linked in.
This was a while ago, and I do not know if I ever found the issue. However, looking back at this, it may have been caused by a breakpoint that had an Action to log to the output window, either referencing a variable that doesn't exist anymore, or the breakpoint being moved due to lines being added/removed by a source control programme, moving the variable out of scope.
Given the output Rect: identifier "posPt" is undefined, the action would have read as Rect: {posPt}.
Maybe it's just a stupid case of PEBKAC, but recently, when fixing C# compiler errors, I frequently run into this problem:
I press enter on the first error (to jump to the code and fix it)
The error gets removed from the list (still normal for JIT code)
Previously, I would now just shortcut to the Error list, press down once, then Enter and fix the next bug. But now the list just seems to put my selection at a random error, not at the next one in the file.
I have the list sorted by error number (2nd column) which seems to coincide with File and Line sorting. I'm using VS2013.
Maybe I changed some setting by accident? Or is that a VS2013 bug? (Haven't been using it for that long, and 2008 never had that problem AFAIK)
PS: It could be the case that that problem has always existed, but I didn't notice because it doesn't happen in C++ obviously, and I didn't have such a mass of errors at once (big refactoring atm)
In Visual Studio, is it possible to edit assembly language code while stepping through each statement (so that statements in the program can be modified while the program is running?) It would be useful to modify statements in a program while the program is running (for debugging purposes), but I'm not sure if this is possible yet.
You can modify the source code, but it doesn't get reassembled to produce a new binary during your debugging session. The debugger will tell you the "source no longer matches the code" but you can still step. Your display may be confusing because, well, the source code no longer matches the object code :-} I often add comments to instructions or in blank lines, which gets me the complaint, but you can still single-step and see the right source lines in this special case.
I think you can manually modify the memory containing the instruction you want to patch. I've not ever bothered to do this; its easier to set a breakpoint where I'm at, re-assemble, and then run till the breakpoint.
You can modify all the registers and data memory pretty easily (actually you have to use this to modify the code memory, I think!).
A really useful thing to do is "Set Next Statement" to set the PC back to a somewhat earlier place in the code; you can often then step forward to point of failure, if the registers and memory aren't changed. (put cursor in your source or disassembly window, click on a line, then right-click "Set Next Statement")
i have found myself several times in the need of knowing the last values set to a range of variables that were in a certain portion of code, or method; maybe dispersed around the program.
does anyone know a way to select variables and know the last value set to them after the program ends running - in a windows maybe ?
There isn't anything I know of that will record every value ever assigned to every variable in your program in case you want to look at it later. It is possible with VS2010's historical debugging abilities to look at "values from the past" although I haven't used this yet, so I don't know if that ability extends "beyond death" of the process.
You may also be able to use tracepoints (VS2008 and later). These are like breakpoints, but instead of stopping execution they simply print information to the debug output. So you could add a tracepoint for a variable so that each time it is changed its value is reported (basically the same as printing the values out in your code, but you don't have to change your code to enable them, and can add them while your code is executing).
Two simple approaches that will work for pretty much any dev environment are:
Write the values to an application log each time they change, then read the last reported entries. If you realise you need 5 values from all around the program, simply printing them to the debug output will only take a few seconds to add to your program. (If you can't do this easily, then you're not encapsulating your data very well).
Put a breakpoint on the destructor of the class you're interested in, or at the start of the shutdown process just before you destroy the objects, or the last line of code in your program (for statics) (etc) and just use the debugger to drill down into the data.