I am having two issues with the debugger using visual studio version 9.0.30729.1 using .net 3.1
Issue one - I hit a breakpoint, and F10, F11 do not move me to the next instruction. If I repeatedly press F10 I will eventually step to the next instruction. I can place another breakpoint further down in the code and do an F5 to get to the next breakpoint - but I miss the ability to step.
Issue two - I hit my first breakpoint, do an F5 or F10 and the program continues without stopping.
These issues seem to occur semi randomly. Sometimes they clean themselves up if I shut down visual studio and reboot my computer - but not always. This does not occur as often in my unit tests as with the GUI application.
Any ideas will be appreciated.
Do you have a great deal of threads in the program? Could be Thread 1 breaks, you step, thread 2 breaks at the same point that thread 1 just broke at
Make sure the source code hasn't changed after you've started a debugger...
Just for giggles, try turning off just my code. Uncheck the "just my code ..." option under (Tools -> Options -> Debugger -> General)
JMC can cause odd behavior in scenarios you wouldn't necessarily expect.
Make sure your .pdb files are current, otherwise the source you're debugging and the source you're running might not match.
Try cleaning up your solution directory by deleting (renaming) all files generated by Visual Studio (*.ncb, *.suo, obj/, bin/, and maybe some more).
Related
I have a .Net web project that I publish and then attach VS to w3wp.exe for debugging. I place breakpoints, load the specific web page being modified, and debug... over and over. This works fine for a while but then it just quits hitting the breakpoints and gives the error: "breakpoint cannot currently be hit, no symbols loaded.." with a hollow circle for the breakpoint. I cannot say what causes it to stop hitting the breakpoints. I'm just coding, publishing, debugging, repeating.... then I'm not. So, I do the following:
delete all debug and release folders,
delete the obj and bin folders
rebuild the solution
restart VS 2022
restart computer
update NuGet
make sure still configured for debug build
I did have some luck deleting all the files/folders in C:\Users\stever\AppData\Local\Temp\2 with today's date. In fact, I thought it WAS the fix because it fixed the issue a number of times and I was able to debug again. However, that stopped working too.
I did all the things mentioned a number of times and finally did get it to hit the breakpoints again. This has happened a lot! It sure would be nice to know what's causing this and what I need to do in order to debug again every time it happens. Any ideas for a fool-proof fix?
After a very long period of not getting this to work, I found something that works 100% for me. When I go to debug, I select "Attach to Process", then click the [Select] button for Attach To. I deselect "Automatically determine the type of code to debug" and manually select .Net 4x or .Net Core depending on what I'm debugging. Then I select the process and debug.
If it doesn't work, I stop the debugger, click [Select], and toggle "Native". Then I attach to the process again and it works every time!
I'm trying to understand the workflow of a project, and want to instrument on each file that is called.
I've tried to use definition/reference to set breakpoint manually, but it's a huge project that it might miss something this way.
I've also used the step forward button in Visual Studio but it just jumps to the very next line, which makes it impossible to trace the entire project.
Is there something that you can jump to the next file, instead of the next line? Or is there some other tools that could help me understand the flow of the codes?
What you probably want to do is:
Step Into Code with F11
Instead of:
Step Over Code with F10
Stepping into code will move into the next method being called. Often times this is located in another file but it doesn't have to be by definition.
Further Reading:
First look at the Visual Studio Debugger
Navigate through code with the Visual Studio debugger
You can use my Runtime Flow tool to understand the workflow of a project. Though it requires some manual configuration to monitor an ASP.NET application.
So I'm trying to add some new code to a project I'm working on, but Visual studio is not cooperating at all.
The project is only hitting breakpoints on code that existed prior to this set of changes. See the screenshot below, where the top and bottom breakpoints are pre-existing code, and some new code is inside the if statement.
I have no idea where to start, I've tried a clean and rebuild, to no avail.
Solved:
Debug Menu -> Options -> Debugging -> General -> Uncheck Suppress JIT optimization on module load
I'm not sure why it decided to start acting up now(haven't had this problem for a year of work on this project), but I'm guessing the code I'm trying to debug was optimized away.
Do a Rebuild All. (I see you tried that--I listed for others to consider.)
Make sure all dependencies for the code in question are current. You might have a project reference to an assembly (DLL) that has since fallen out of sync with its PDB/source code. Be sure all references point to currently compiled code.
I've sometimes seen this happen and an exit/restart of Visual Studio (all instances, just to be safe) works.
If any of these ideas work, please let us know which one did.
I went through the same issue, tried everything above and the solution for me was to do: Debug > Delete all breakpoints to start fresh.
I have a strange error. I'm debugging an asp.net site and suddenly it stops. Visual Studio stays in debug mode and my web application stays on running just fine. I found this post on, but I don't think a background thread is causing the problem. There's even a try catch around the code where it usually stops debugging, but the catch is not triggered... Everytime I try it, it stops at a different place in the code.
Have you set your debugger to break on all exceptions, not just unhandled exceptions?
Debug -> Exceptions -> Check the "Thrown" box for everything (or at least just Common Language Runtime Exceptions). If an exception is thrown during debugging, on any thread, this should cause the debugger to highlight and break on the "thrower".
Another thing to try, is to reset all your IDE settings. I've had various odd behaviours before where settings got corrupted and the IDE stopped behaving sensibly: Tools -> Import and Export Settings -> Reset All Settings.
In addition to Daniel Dyson's answer - if you "pause" as he suggests (once the debugging has "stopped"), open the "Threads" debug window. Are there any threads showing that have an entry in the "location column". If so, this is probably your code executing. Click on each in turn. Can you account for what each thread is doing, or does this shed any light on this odd behaviour?
Have you tried hitting the Pause || button? This will pause the debugger wherever it is executing, so if you are in an infinite loop outside of your try catch block, you will be able to find out where.
Add a breakpoint in Application_Error Event in the Global.asax.
Check mode in your ide its set to Debug not to Release.
Because cannot able to debug your application if it set to Release mode.
check for detail : http://msdn.microsoft.com/en-us/library/e8z01xdh(VS.80).aspx
Make sure the "Ping Enabled" setting is set to "False" in the IIS configuration.
In IIS7, right-click on your AppPool, choose "Advanced Settings," navigate down to the Ping Enabled setting and change it to false.
If you're using IIS6, the setting is slightly different. I believe it's called "Ping Interval" if I remember correctly and it's set to a number of seconds.
I solved the same problem. I post the solution here, hope it'll help someone in the future.
Here is my condition:
I use Visual Studio 2015 to debug my game on Unity (visual studio tools for unity)
After a few minutes of debugging, the debugging arrow disappear.
What cause it:
I had enabled "Show Threads in Source Code".
Solution:
Disable "Show Threads in Source Code", then restart Visual Studio (and Unity if you're using Unity).
Run debugging to make the button "Show Threads in Source Code" appear.
Disable "Show Threads in Source Code".
Close Visual Studio (and Unity).
Open Visual Studio (and Unity)
For some reason when I press F10 to do a regular build of my project, it builds then launches with a breakpoint/arrow thing on the first curly bracket of my Main function.
What is causing this? It only happens every other time I build and it's quite annoying.
F10 is the "Step Over" debug command. The fact that it's being built is a side effect of the editor tracking changes that you've made since the last time the project was run. So it's doing exactly what you've asked - Debug the project and step over the first instruction.
The default code to build the project is Ctr+Shift+B.