I'm having a weird problem where breakpoints that are currently hit are not fully highlighted, which causes them to be only partially evaluated. See image below. The statement the debugger is on returns true. However, the debugger does not go past 'products' and thus it goes to the end of the if statement. It can happen to any line of code regardless of length. Also, the point at which the highlighting drops off is random, sometimes it will only highlight the first letter.
Example:
I use Attach to Process (on all w3wp.exe instances) for this project. When not debugging the whole line is highlighted as it should be.
I have tried the following:
Clean & ReBuild Project
Deleting bin & obj folders and restarting VS
Deleting all breakpoints and resetting one or two
Restarting computer
Deleting .SUO file
Trying the solutions in this somewhat-similar topic
I'm not sure what I'm missing here.
This happens when Visual Studio is stepping through compiled code that does not match the source code displayed in the IDE. Among other things, the generated pdb tells VS how long an individual line of code is in order to properly highlight it on a breakpoint; the "incomplete highlighting" indicates that VS is executing a line of code with a different length than the actual line indicated. You need to completely clean and rebuild everything. I know you indicated that you tried that, but something is persisting or not being built correctly.
You can also try going to Debug > Options and Settings, checking "Require source files to exactly match the original version", and building/running again. This should be additional confirmation that there is a mismatch between what you're looking at and what's being compiled.
Related
EDIT: When I run this code in Visual Studio 2013, the debugger is showing Utc, not Local. It's a bug in Visual Studio 2015 Debugger.
EDIT: Have taken the code and put in stand-alone console app, but cannot reproduce in either version of VS. Bummer.
Can someone explain to me how what you see in this screenshot is possible?!
On line 298, endingTimePeriodStartDate is redefined as its Date value but set to DateTimeKind.Utc.
On Line 300, if endingTimePeriodStartDate is not actually DateTimeKind.Utc, an exception is thrown.
The debugger breakpoint on line 305 is hit, meaning the exception on line 302 was not thrown, meaning endingTimePeriodStartDate.Kind == DateTimeKind.Utc
(I also did a System.Diagnostic.Debug.WriteLine(endingTimePeriodStartDate.Kind) before line 305 and it prints “Utc” in the Output window).
When I look at endingTimePeriodStartDate in the Locals and Watch debugger windows, and when I mouse hover over the variable, the Kind property shows DateTimeKind.Local
Usually the debugger will show wrong line numbers, and go into old code if it is running a different version of the dll (a former version) than the one that your code is showing. This happens
when there is some kind of caching
when the former running version wasn't closed correctly, or is still running in another process.
when the Visual Studio is not pointing to the correct code
Usually to fix this, you should:
(Start by trying only a "clean" and "rebuild")
Stop all running or debugging Visual Studio projects.
Close all your Visual Studio solutions and windows, so that Visual Studio is not running.
(If next step doesn't do the trick, then the next time around reboot your computer as well before going on to next step)
Re-open only the solution you need to run. Hit "Clean solution". Then "Rebuild solution".
Check if this fixed the problem.
Manually delete the bin folders: (if the clean/rebuild didn't work)
5.1 If your afraid, backup your whole source directory. After everything works, delete the backup...
5.2 manually go into the dependent projects (that are referenced in your "wrong code showing" project) and in each one of them, go into the obj and into the bin folder and delete everything that was automatically created from there - in other words, everything that you did not put there manually. Usually that's everything. Don't worry, visual studio will re-create the Debug and Release directories and fill them up.
Delete the obj and bin of your project as well.
Rebuild everything.
I am working on a C# and Silverlight project and every once in a while I run into an issue where my breakpoints are no longer getting hit when I debug. In the editor they are not turning transparent so I know the correct code is loaded and being run.
An example would be:
I have Value with a getter and setter and it is bound to a control. When I put a breakpoint in the setter and I change the value of Value from the control the breakpoint is not getting hit.
I know that an IIS reset fixes this problem but I would like to know the cause. Does anybody else find similar behavior? If anybody would be able to point me in the direction of a possible cause that would be much appreciated.
There is an option in Visual Studio 2010:
Tools -> Options...
Debugging -> General
"Step over properties and operators (Managed only)"
Make sure this isn't checked. This assumes that the breakpoint is a solid red circle, indicating that VS has found debugging symbols for it.
Alternatively, these elements of code could be decorated with one of various debugging attributes, namely DebuggerStepThroughAttribute, DebuggerNonUserCodeAttribute and DebuggerHiddenAttribute. These may stop the debugger from going into the method, even if a breakpoint is there.
Of course, if the code you are debugging has been optimised, it may look like it's missing lines. I'm not sure what happens if you try to breakpoint a line that has been optimised away.
If the breakpoint has gone hollow (not solid red), then Visual Studio likely cannot find the debugging symbols for the code.
If a reset fixes the issue, perhaps there are differences between the code being debugged and the original source file / symbols, there is an option to make this less strict:
Same options area as above.
"Require source files to exactly match the original version"
Many times i face this problem though while on winforms apps. So simple thing i do is, restart VS prior to Clean and Rebuild the solution. Then if nothing works out, just delete the bin directory and let rebuild again. The last option i do is restart machine.
I've had this problem recently. While I did not find the exact cause, a simple fix was to check the app is running in debug mode (as opposed to release) and clean / rebuild the solution.
Found this question while trying to understand why my own project's breakpoints weren't being hit while trying to run code in vs2010
Solved it by looking at the project properties under Advanced Compile Options and setting Generate Debug Info to Full.
Might be worth mentioning I jump into code I wish to debug by using the very handy TestDriven.net's "Test With -> Debugger" via a right click on the function I wish to debug.
(At least) Two potential causes: Visual Studio options, or ReSharper options
Example: if I break at some call like Console.WriteLine(myVar.myProp), and I also break inside the myProp getter, the breakpoint inside the getter will be completely skipped if the following settings are still turned on.
For the Visual Studio Options:
And for the ReSharper Options:
So, turn these off to avoid datatips from causing your breakpoints to be skipped.
I am unable to put a breakpoint.
I am getting the message in the breakpoint like:
"break point will not be currently hit, no symbols are loaded"
there are a few solutions. The problem is that the symbols loaded dont match the executable.
1) Make sure the exe you are attached to have its PDB's in the same directory and its the same version
2) make sure your source code is the same version as well
3) when debugging , open the modules window (debug --> windows-->modules). Choose load symbols and choose your pdb
If your unsure on what to do, then rebuild everything and run
oooops . i didnt read your post properly, i assumed your using visual studio. Anyway, if your not , just find where in your IDE you need to set the symbols and check there.
Another issue is that the breakpoint is that it may be set to a blank line.
Sometimes if I have another instance of Visual Studio open as well as the one I'm trying to debug with, it plays up, especially if I've been debugging in that other one.
I have a .net 1.1 project in VS.Net 2003 (using C#) in which I can set a breakpoint in one method, and step through code just fine, but when I hit one specific method (which we also wrote), the breakpoints and code pointers go "whacky", for lack of a better term. If the breakpoint is on line 100, the execution pointer stops on line 101. The syntax highlighting that colors the breakpoint red will still be on 100, but it will only be as long as line 101 is (which is to say, shorter than line 100). As you F10 through the code, the deviance between where the code is really executing and where the execution pointer is placed appears to get bigger. Has anyone ever encountered this type of problem before, and if so, what might be a solution to resyncing things so I can accurately debug my program?
Yes. Your debug symbols (.pdb files) are out of synch with the actual code. Close Visual Studio and delete the "bin" and "obj" folders from all of the affected projects. Then reopen Visual Studio and rebuild. This should resolve the problem.
Found it... my PDB files got out of sync with the DLL files... cleaned the /bin/ folder and rebuilt, and the problem goes away.
Thanks me. :)
I'm working in VS 2008 and have three projects in one solution. I'm debugging by attaching to a .net process invoked by a third party app (SalesLogix, a CRM app).
Once it has attached to the process and I attempt to set a breakpoint in one of the projects, it doesn't set a breakpoint in that file. It actually switches the current tab to another file in another project and sets a breakpoint in that document. If the file isn't open, it even goes so far as to open it for me. I can't explain this. I've got no clue. Anyone seen such odd behavior? I wouldn't believe it if I wasn't seeing it myself.
A little more info: if I set a breakpoint before attaching, it shows the "red dot" and says no symbols loaded...no problem...I expect that. When I attach and invoke my .net code from SalesLogix and switch back to VS, my breakpoint is completely gone (not even a warning that the source doesn't match the debug file). When I attempt to manually load the debug file, then I get a message that the symbol file does not match the module. The .pdb and the .dll are timestamped the same, so I'm stumped.
Anyone have any ideas?
Thx,
Jeff
I saw this functionality in older versions of VS.Net (2003 I think). It may still exist in current versions, but I haven't encountered it. Seems that files with the same name, even in different directories confuse VS.Net, and it ends up setting a break point in a file with the same name. May only happen if the classes in the file both have the same name also. So much for namespaces I guess.
You also may want to check your build configuration to make sure that all the projects are in fact building in debug mode. I know I've been caught a couple times when the configuration got changed somehow for the solution, and some projects weren't compiling in debug mode.
Kibbee, you were right! It was two files with the same name in different folders. I was setting the breakpoint in the correct file on line 58 - it was putting the breakpoint on the other file at line 58. I was finally able to set a breakpoint by using the "Debug-->New Breakpoint-->Break at Function Name" menu option and entering my function name. It stopped exactly like it should have then.
I agree - so much for namespaces, right? Damn thing cost me a couple of hours. Oh, well...at least it's solved and I know why.
Thx for the answer and thx to Matt for his reply, too!