VS 2005
For example,
My employees gave me a project with about X try-catch statements.
X > 100 .. 300
I need to test a project. Is there a way to mark each (every) beginning of catch as a breakpoint ? I don't want to do it manually. Maybe there is some settings that fit to me ?
Go to Debug > Exceptions (Visual Studio 2013 and earlier) or Debug > Windows > Exception Settings (Visual Studio 2015 and later).
In this dialog you can enable first chance debugging of exceptions - when an exception is thrown, the debugger will automatically break at the throwing code before the "catch" code is executed, allowing you to debug it.
What you want to do is ask it to break when CLR exceptions are thrown, not only when they're unhandled (image from Visual Studio 2013 - 2015 is similar but now is in a view rather than a dialog):
(Note: This won't get the debugger to break whenever you execute a try block, only if the exception is actually thrown)
Short answer is no. But you might be able to make some an aspect-oriented plugin to your project that captures the catch crosspoint, then you just have to put one breakpoint at in your aspect
I am not aware of a possibility that allows setting breakpoints in code by some pattern. The closest you can come to is Debug/New breakpoint/Break at Function where you can specify the file and line number. If you can get this automated and working down a list generated by a grep search, you might find a way. Here is something from the IDE samples that might get you started:
' Sets a pending breakpoint at the function named "main". It marks the
' breakpoint as one set by automation.
Sub AddBreakpointToMain()
Dim bp As EnvDTE.Breakpoint
Dim bps As EnvDTE.Breakpoints
bps = DTE.Debugger.Breakpoints.Add("main")
For Each bp In bps
bp.Tag = "SetByMacro"
Next
End Sub
However, why do you want to set those breakpoints anyway? If it's in order to catch exceptions as they are thrown, you can make the debugger break automatically whenever the happens under Tools/Exceptions.
You can use this if you are using older IDE's (anything pre-2012)
Programmatically apply / deactivate breakpoints in Visual Studio
Unfortunately they removed the macros from the newer IDE's.
There are extensions you can download and one of them allows you to modify a *.js file. Issue is going to be converting what the gentleman wrote in the other post to have it read properly.
For now I'm just using System.Diagnostics.Debugger.Launch(); it's just a pain and it would be awesome if someone could translate that file over.
Related
Going mad here!
Visual Studio is ignoring breakpoints, skipping with a "The breakpoint will not currently be hit. The source code is different from the original version" alert and the breakpoint turns white.
Simple test - new WinForms project with a few lines in the form load event.
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Console.WriteLine("1")
Console.WriteLine("2")
Console.WriteLine("3")
End Sub
Set a breakpoint on any of those lines, I get the above error, the console outputs as expected (1/2/3) and the form loads with no pause break.
Fresh boot of PC makes no difference.
Running VS 2013, Update 4, on Windows 7 x64.
Jim
In my case I was trying to run the unit test via a test agent. This does not allow debugging to occur. I changed my testsettings.settings file so that the role read "local" instead of remote, and then I was able to debug.
I also came across same problem. I rebuild my solution and checked Warnings. There were several warnings, one was of reference missing, due to which break point was ignored. As i fixed the reference missing warning, it started working.
How do I set a breakpoint on an exception?
Ideally I want to be able to see the call stack and local variables from the code that threw the exception.
I haven't used Visual Studio for 2 years, but from memory:
Ctrl + Alt + E
Will bring exception management screen, make sure to check break on all exceptions, a must have imho :)
EDIT : My memory not that bad :) Just check Thrown on Common Language Runtime Exceptions if your are using .NET (CLR = .NET)
EDIT 2 : By the way, since exceptions are generally a bad coding practice and should be avoided as possible, i suggest to let that option enabled all the time. If some exceptions just can't be avoided (because of someone else, of course :D) just uncheck its type or ancestor in the exception type tree.
The exact visual studio command name is Debug.Exceptions
Main Menu > Debug > Exceptions (when solution is open)
Also, make sure you're running in debug mode and that debugging is enabled in the project properties or else all the breakpoints in the world will count for nothing.
(Depending on your environment you can also click on the margin outside the code source to insert a breakpoint via mouse action)
I am getting difficulty debugging my custom IIS module written in C++, using VS 2010. The problem is that IIS worker process (w3wp.exe) starts too quickly and there is no way to catch it at the beginning in VS "attach to process" dialog. Is there a good skill to do this? Thanks.
You can add a Debugger Breakpoint in your code . I use this all the time to catch things that are too fast to catch manually.
FYi in .net you use System.Diagnostics.Debugger.Break() to achieve the same effect.
It causes the windows system debugger to be activated.
A trick that I have sometimes used is to introduce an artificial infinite loop at the entry point of my code, I then set a breakpoint in this loop and simply move the next instruction to be out of the loop when the breakpoint is hit - job done!
In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.
Normally in Visual Studio, a watch cannot be evaluated unless the debugger is stopped at a breakpoint. Is there a trick or add-on to make Visual Studio evaluate a watch while the application is still running? For example, evaluate the watch every time execution passes a point in the code while it's still running and without changing the code to insert statements like Debug.WriteLine.
Not sure this is possible, but I thought I'd ask.
Yes, this is possible. Set a breakpoint at the location where you'd want to see the value. Right-click the breakpoint and choose "When Hit...". Tick "Print a message" and write an expression like { value }. The message is displayed in the Output window while your program runs.
I would do that using compiler directives.
#if DEBUG
Debug.WriteLine
#end if
No this is not possible to do. The evaluation feature in Visual Studio is a stack frame based mechanism. That is that every evaluation is done in the context of a given stack frame (as viewed through the stack window). When the program is running the set of stack frames is currently changing and hence it's not possible to do a stable evaluation.
Additionally there are other limitations in the CLR which prevent this from managed code. It's not possible for instance to execute a function unless the debugee process is in a very specific state.