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}.
Related
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 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.
Is it possible for the debugger (or the CLR exception handler) to show the line where the exception happened in Release mode using the pdb?
The code, in release mode, is optimized and do not always follow the order and logic of the "original" code.
It's also surprising that the debugger can navigate through my code step by step, even in Release mode. The optimization should make the navigation very inconfortable.
Could you please clarify those two points for me?
I'm not as familiar with how this is done with CLR, but it's probably very similar to how it's done with native code. When the compiler generates machine instructions, it adds entries to the pdb that basically say "the instruction at the current address, X, came from line 25 in foo.cpp".
The debugger knows what program address is currently executing. So it looks up some address, X, in the pdb and sees that it came from line 25 in foo.cpp. Using this, it's able to "step" through your source code.
This process is the same regardless of Debug or Release mode (provided that a pdb is generated at all in Release mode). You are right, however, that often in release mode due to optimizations the debugger won't step "linearly" through the code. It might jump around to different lines unexpectedly. This is due to the optimizer changing the order of instructions, but it doesn't change the address-to-source-line mapping, so the debugger is still able to follow it.
[#Not Sure] has it almost right. The compiler makes a best effort at identifying an appropriate line number that closely matches the current machine code instruction.
The PDB and the debugger don't know anything about optimizations; the PDB file essentially maps address locations in the machine code to source code line numbers. In optimized code, it's not always possible to match exactly an assembly instruction to a specific line of source code, so the compiler will write to the PDB the closest thing it has at hand. This might be "the source code line before", or "the source code line of the enclosing context (loop, etc)" or something else.
Regardless, the debugger essentially finds the entry in the PDB map closest (as in "before or equal") to the current IP (Instruction Pointer) and highlights that line.
Sometimes the match is not very good, and that's when you see the highlighted area jumping all over the place.
The debugger makes a best-effort guess at where the problem occurred. It is not guaranteed to be 100% accurate, and with fully optimized code, it often will be inaccurate - I've found the inaccuracies ranging anywhere from a few lines off to having an entirely wrong call stack.
How accurate the debugger is with optimized code really depends on the code itself and which optimizations you're making.
Reference the following SO question:
Display lines number in stack trace for .NET assembly in release mode
You're stepping through C/C++ code and have just called a Win32 API that has failed (typically by returning some unhelpful generic error code, like 0). Your code doesn't make a subsequent GetLastError() call whose return value you could inspect for further error information.
How can you get the error value without recompiling and reproducing the failure? Entering "GetLastError()" in the Watch window doesn't work ("syntax error").
As mentioned a couple times, the #err pseudo-register will show the last error value, and #err,hr will show the error as a string (if it can).
According to Andy Pennell, a member of the Visual Studio team, starting with VS 7 (Visual Studio .NET 2002), using the '#' character to indicate pseudo-registers is deprecated - they prefer to use '$' (as in $err,hr). Both $ and # are supported for the time being.
You can also use the $err pseudo-register in a conditional breakpoint; so you can break on a line of code only if the last error is non-zero. This can be a very handy trick.
Some other pseudo registers that you may find handy (from John Robbins' outstanding book, "Debugging Applications for Microsoft .NET and Microsoft Windows"):
$tib - shows the thread information block
$clk - shows a clock count (useful for timing functions). To more easily use this, place a $clk watch then an additional $clk=0 watch. The second watch will clear the pseudo register after the display of the current value, so the next step or step over you do gives you the time for that action only. Note that this is a rough timing that includes a fair bit of debugger overhead, but it can still be very useful.
ERR,hr in a watch window usually does the trick
"edit and continue" add the code so you can see the error (just don't create a new global variable to store it). It works really well if you can quickly put a call to a pre-existing function that executes this kind of error handling code.
As a bonus, you can leave the new code there for the future too.
If you can't do this, then QBziZ is right "ERR,hr" does it.