Occasionally during debugging the debugger skips forward randomly. Sometimes I Step into a function inside of another function and instead of going to the next line it skips through to a seemly random place in the future. sometimes to a line partway through another function.
It always seems to respect breakpoints though, i.e. if a breakpoint is set in the future it never will skip past it.
I'm running 64 bit Win 7 and visual studio 2010 ultimate. I'm not using threads. This never happened for me in visual studio 2008. How can I fix this?
Do you have optimizations turned on? If the program is highly optimized, the order of execution can be thrown off, and things can be expanded or rearranged in ways that are not always clear.
I'm running into similar problems debugging a C# program with Visual Studio 2010 on an XP machine. The debugger just randomly skips to some other line or the next break point.
It seems that Microsoft has released a Fix for this in the SP1.
Are you sure that the assembly your code calls has debug symbols? You maybe referencing a dll that was compiled in release mode.
This can happen when the debugger is running against pdb files that don't match the source code you are looking at. Make sure the bin (or where you are running from) is up to date and was built from the same source code you are running in the debugger.
Are you using threads or background workers? When debugging I believe that all threads are paused so it could be switching between them. Otherwise you may have out of date debugging information, Delete your bin and obj directories and do a clean build.
This can also happen when your Debug solution configuration is up to date, but you try to debug the program in Release configuration (if that is not also up-to-date)... or vice versa.
You can switch back and forth between running in Debug or Release configuration using the drop-down next to the green 'play' arrow at the top of the screen.
I had a similar problem in Visual C++ 2008 on Windows 7 32-bit recently. Several minutes before the problem first appeared, a system dialog window “VC.exe encountered a problem and needs to quit” was displayed but the Visual C++ window seemed to survive.
After the problem first appeared, I tried several ways to getting it back to work like rebuilding the solution or restarting Visual Studio. However, it continued to behave strange: It failed to link with an object file I hadn’t touched for weeks, displayed “The breakpoint will not currently be hit. The source code is different from the original version.” etc.
Nothing helped until I rebooted the computer and finally rebuilt the solution (twice, actually).
Click Rebuild Solution.
Related
I need some help. I have put in dozens of hours into a VB.NET project, it has been built in release mode and distributed. Now I have to make some changes to it, and I am unable to debug it properly. My code changes result in behavior where my code is not even recognized.
Also, I installed Visual Studio 2013 recently (moving from 2010), but this project behaves the same in both environments.
I believe that my code has become 'optimized'. The error window tells me that code is being skipped over, and that my code is optimized and JIT is checked.
I have turned off JIT, and I have tried everything to make this project work again that I could think of. I am desperately wanting to know how I can get this project to be in a state where it will debug each line of code again when I make changes.
I can even purposely write bad code, and the debugger does not see it.
This project is now in debug mode, not release. I have checked and followed threads on every thing that other people have done to solve this issue, but nothing works for me.
Either my project launches and works properly as it is coded, or if I change any code only the form launches with no code being run - at all.
please help.
I finally figured it out. The applications that I was struggling with were all built in Visual Studio 2010 on Windows 10. I was trying to work with these in Visual Studio 2013 on Windows 7.
Once I tried to work with them on Windows 10 (visual Studio 2013 this time), they started working and debugging just fine.
I think it may have been DLL assembly paths? Took me more than a week, but I figured out my issue by moving from Win7x64 to Win10x64.
Yesterday I wanted to continue working on a project of mine, so I started Visual Studio and asked it to run the project to remind myself, what was already implemented and what wasn't.
The project got built and started, but seemed to quit right away. No error message, nothing.
No matter what I did, whether I rebuilt the project or cleaned it, nothing changed.
This didn't make sense, since the last time I tested the project, it worked perfectly (and I didn't modify anything in the code since then)
So, I assumed I had a hidden bug somewhere in the code, that just didn't show up previously.
I put a Breakpoint somewhere near the beginning of the code, and ran the project.
As expected, Visual Studio paused the execution at the Breakpoint and highlighted it.
I decided to set another Breakpoint somewhere later in the code and continue execution, but before I could even move my mouse, the project stopped.
Restarting Visual Studio didn't help, but restarting the PC did. Therefore, I'm assuming that something on my system was terminating my project, shortly after execution begun.
Now my question is: What exactly happened, and especially: why did it happen?
The problem came back while I was writing this question. I don't feel like restarting my PC every couple of hours...
I really appreciate the time you took reading this and I look forward to your answers.
I'm aware that I'm answering my own question, but since I've solved it myself, I thought others might want to know how I did it (for the sake of future generations)
The thing is: I've recently added Visual C++ to Visual C# before Visual C# started having problems.
So I deduced, that maybe the installer for Visual Studio messed up with something and decided to reinstall Visual Studio.
Problem solved.
So: if your projects stop without warning even while paused on a Breakpoint and you've changed something in your Visual Studio installation (like added Visual C++ in my case), you might need to reinstall the whole thing.
Luckily, the Visual Studio installer offers a "Reinstall" option, so you don't need to uninstall and reinstall manually.
I found about this solution, after talking to a more experienced colleague. I just wish I asked him first. Still appreciate your efforts in the matter, though.
EDIT:
I recently noticed a similar bug acting up for C++ programs this time, where the window border would be outlined in red. The thing is: it's not Visual Studio's fault, but in fact Avast Antivirus' fault. More specifically, its Sandbox mode.
So, if for any reason, you notice programs quitting without crashing, shortly after starting and their window border having a red outline, you're very likely using Avast Antivirus and should deactivate the Sandbox mode.
Happens to me from time to time.
Sometimes closing and opening VS helps, sometimes you have to restart the computer.
I assume it must be related to some DLL or something that is loaded into memory and corrupt, or something like VS loosing the reference to it, and not unloading it correctly/replacing it.
I also once had this strange bug, where I started VS, just like any other day, and my project crashes instantly with some H_RESULT error (some DLL related Error) upon run. After having spent around 1hour searching for the source of the problem, I went into the reference section, and what did I see there : the worst possible circular reference ever : my business project had a reference to ... itself ! The kind of stuff you could not do if you wanted to.
The weirdest part of this, must of been that VS managed to compile the project, and it only crashed while trying to run it ...
I'm using the latest NUnit, 2.5.9, on Windows 7 64-bit, Visual Studio 2010 Premium, and the projects are .Net 3.5.
The problem is that I attach to NUnit (there is NOT an nunit-agent appearing), and symbols are loading, but my break points aren't being hit. There is no error indicator next to the breakpoint indicating something is wrong.
The first run seems to take some time to start the test, but subsequent runs after that seem to complete almost instantly. I assume because StructureMap (required for the objects i'm testing) has already done its thing and doesn't need to repeat that setup.
Any ideas on how to fix this?
I sort of figured out the answer. I reset all of my settings to the standard Visual C# Development Settings and debugging suddenly works again.
I'm not sure which setting got everything back on the right track; I didn't see a "disable debugging while debugging setting."
Following my last question (see: Problem in hosting ActiveX on Vista (in a Visual Studio 6 C++ application)) I ran into a strange problem. I hope this’ll be a simpler issue to the experts here:
Each time I run certain application like iexplorer or firefox, the Visual Studio 6 suddenly opens up in debug mode with a message “User breakpoint called from code at 0xSOMETHING”.
I can press F5 to continue but the applications run slowly and needless to say I have no wish to debug these applications…
My guess is that when I worked on my VC++ application I placed breakpoints at windows methods like CAxDialogImpl::Create(), AtlAxCreateDialogA() etc’, and for some reason it was kept somewhere.
Of course I now removed all the breakpoints and re-compiled the project but still this keeps happening!
I checked in the tools->options but the “Just-in–time debugging” is not marked.
Any idea?
(I use Visual Studio 6 which I installed on Vista)
Thanks a lot,
Erik
Not sure this helps but anyways:
Try disbaling the default debugger option. (It says Dr. Watson but it depends what you have set as the default debugger)
http://www.bridgetonova.com/2007/09/how-to-disableenable-windows-default.html
Also as per this post Visual Studio 6 is not supported on Vista. Only Visual Basic is.
http://www.itwriting.com/blog/167-visual-studio-6-on-vista.html
You should probably re-ensure yourself that you have removed all calls to DebugBreak() and manual break-points. Also try to ensure that when you recompile you re-register everything to point to the right places (i.e. the activex pointed to by the guid in the registry is actually the latest recompile).
When I hit F5, my VS 2008 opens my site in IE and halts. There is no sign in VS that the project is running. It enables the RUN button again even though the site is opened in IE. Hence, my breakpoints are also not working.
This behaviour started happening suddenly..
Any reasons why it happens and resolutions?
Are you building in Debug mode? Release builds don't support breakpoints...
One reason I have personally experienced:
Problem:
Running two separate Solutions in their own instance of Visual Studio 2008
Solution:
I closed both instances of VS, then started only one.
Conclusion 1:
Visual Studio might have a problem when RAM is limited and silently disable breakpoints (fail)
Conclusion 2:
Visual Studio might share some critical resources needed for breakpointing which the first instance holds onto and (again silently) the other instance won't even give you an error.
Lots of bugs and fail in Visual Studio.
This is a bit late, but in case anyone else has this problem, I'll post these two links that helped me when I had a similar problem:
Forum describing similar problems: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193
Solution listed in the forum was this patch: http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796