We Keep Coding

Is there a way to measure time between breakpoints without stopping in visual studio?

If I put down 2 breakpoints I can measure the time between hitting the breakpoints. This is displayed in the 'Diagnostic Tools' window under the tab 'events'.
When the debugger stops execution at a breakpoint or stepping operation, the elapsed time between the break and the previous breakpoint appears as a tip in the editor window. For more information, see PerfTips: Performance Information at-a-glance while Debugging with Visual Studio.
https://learn.microsoft.com/en-us/visualstudio/profiling/perftips?view=vs-2019#perftips-1
However most of the time I setup the breakpoints to continue executing and show a message in the output instead, like so:
The problem is, these don't show up in the 'events' tab and therefore I cannot see the execution time between hitting of the breakpoints:
My question comes down to: Can I get the execution time between breakpoints that continue execution instead of breaking with the visual studio debugger?
In this particular case I'm working with an external service of sorts, and breaking the application causes issues with accurate measuring of the time and other side effects. The point is, I cannot and prefer not to use a regular breakpoint.
Please note that I'd like get information about the visual studio debugger and not a separate performance profiling tool or something like that, I'm just wondering if this is possible.

Cannot edit after using 'Break All', although break points work fine

This seems to be a WPF-specific issue.
If I set a breakpoint in the code, the program will pause when it reaches that line, and I can edit/add/remove code, and then continue - it runs the newly edited code (ie, it behaves as expected).
However, if I hit 'Break All', I get moved to window that says "Your App has entered a Break State...". If I try to edit my code, nothing happens. I try to type but nothing happens - no text appears, and there's no errors that pop up or anything.
I don't have this problem in WinForms applications - just WPF. If I create a basic WPF project from the template, I still have the issue.
It's a very frustrating issue! My ugly hacked solution is to add a button to my program's UI called 'Break', which executes a single line of code that has a breakpoint on it, basically recreating the behaviour that 'Break All' should have.
Weirdly, it's not an issue if I'm on a WPF project which uses multiple threads. Hitting 'Break All' in this case acts as if there's a breakpoint on the line of code where the background thread is set up.

I am not sure..but you can give a try.
To enable/disable Edit and Continue. In the Options dialog box, expand the Debugging node, and select Edit and Continue. In the Options dialog box Edit and Continue page, select or clear the Enable Edit and Continue check box. The setting takes effect when you restart the debugging session
source:https://msdn.microsoft.com/en-us/library/ms164926.aspx

How to debug a single thread in Visual Studio?

I have a solution with some projects. There are several break-points in different projects. I want to trace the first thread hit one of these break-points and continue tracing that single thread despite of other threads entering the same code-blocks.
I know this is possible through defining a condition on the break-point, that is, thread name = ... or thread Id = ... but my case is a heavy loaded ASP.NET application and as soon as I attach to w3wp.exe many threads will hit the break-points. I need some thing like a ThreadLocal<break-point>.
Is it possible? If so, how?

Here's what I did:
Set a conditional break point that I
knew would only hit on the thread
that I was looking for.
Once the breakpoint hits and you are in the thread you want, in the Visual Studio Threads window (while debugging, Debug -> Windows -> Threads), Ctrl + A (to select all threads), and then Ctrl + click the thread you are currently on. You should have all threads except the one you want to debug selected.
Right-click, and choose "Freeze".
Now, Visual Studio will only step through the thawed thread. It seems to be much slower when doing this, presumably because it has to loop through all of the frozen threads, but it brought some sanity to my multi-threaded debugging.

Freeze/Thaw threads is an incorrect way because other threads don't execute any code.
The most correct and usable way is to:
Hit Ctrl+A in the breakpoints window (select all breakpoints).
Right click and select "Filter...".
Enter "ThreadId=(current thread id)".
In Visual Studio 2015 and newer, the process is similar:
Hit Ctrl+A in the breakpoints window (select all breakpoints).
Right click and select "Settings...".
Check "Conditions" and select "Filter" in the dropdown
Enter "ThreadId=(current thread id)".
So all threads are executed, but the debugger hits on the current thread only.

If multiple threads are being spawned as for a web application, #MattFaus answer's will not work. what I did instead is the following
Set up a breakpoint to interrupt the thread in the function I want.
Once the thread gets to the breakpoint and is paused, I remove the breakpoint and continue debugging using F8,F10 and F11, so that the others threads can run.

I have just released a Visual Studio 2010+ extension that does exactly what you are looking for.
And it's free :).
Presentation
This Visual Studio extension adds two shortcuts and toolbar buttons to allow developers to easily focus on single threads while debugging multi-threaded applications.
It dramatically reduces the need to manually go into the Threads window to freeze/thaw all threads but the one that needs to be followed, and therefore helps improve productivity.
Features
Restrict further execution to the current thread only. Will freeze all other threads. Shortcut: CTRL+T+T or Snowflake button.
Switch to the next single thread (based on ID). Will change current thread and freeze all other threads. Shortcut: CTRL+T+J or Next button.
Check it out here on the Gallery, on the official page or the Github repository.

A slightly different approach which I've used:
Create a normal breakpoint and let it get hit
Look in your threads window for the managed thread ID that you're current debugging
Right click your breakpoint in the breakpoints window and selecter filter
Enter ThreadId=xxx where xxx is the thread ID from 2
You can now debug without stopping other threads and without them hitting your breakpoint
This assumes you have time to do the above before a second thread hits your breakpoint. If not and other threads hit your breakpoint before you've done the above you can right click them in the threads window and choose freeze.

In VS 2019:
Set a breakpoint somewhere.
Hit F5 (Continue) until your thread comes.
Click on breakpoint to remove it.
You can step the thread with F10 or F11.

Set a Breakpoint Condition by right clicking the side bar of the line. Select "Condition" and enter the following with the name of your thread in quotes:
System.Threading.Thread.CurrentThread.Name=="name_of_your_thread"
Alternatively you can do the same by getting the thread's "Managed ID" from the "Threads" Window and use:
System.Threading.Thread.CurrentThread.ManagedThreadId==your_managed_thread_id

I would suggest adding another instance of the application on the live server, either on the same hardware or a new machine (cluster it) and then debug only that instance. I wouldn't add a breakpoint in code users are triggering. If that's not an option, I'd add more tracing.
However, if this is absolutely necessary and you need a solution stat, I'm sure you could add a breakpoint that breaks only if the request is coming from your IP address. You would do this by adding a conditional breakpoint that inspects HttpContext.Request.UserHostAddress. Note however that this slows down your application considerably.

If you don't want to stop all other threads (maybe you are attaching Visual Studio debugger to a running application that needs to answer to requests), you can use a macro that create and remove breakpoints automatically.
This is suggested in an answer to Stack Overflow question "Step over" when debugging multithreaded programs in Visual Studio.
However, the link only explain how to debug line by line. I suggest you modify the macro (if you're comfortable with it) to make it modify all breakpoints (in a given range of line for instance) to stop only on the current thread.

I think this is slightly different in Visual Studio 2015. They've changed a few things in the breakpoints, but here's how to apply the accepted answer from hzdbyte (above):
On the breakpoint in the coding margin, Right-Click > Conditions > Change from 'Conditional Expression' to 'Filter'. This then allows you to filter by ThreadId.
Alternatively on the breakpoint in the Breakpoints window, Right-Click > Settings > tick the Conditions box and do the above.

in VS2019, the conditional breakpoint is tid == xxxxx
this way the breakpoint will be hit only on that thread

TL;DR; Just press F5 when it jumps to the wrong thread.
I'm debugging a multithreaded queue processor in Visual Studio Pro 2022 Preview, I placed a breakpoint at a point where each queue item being processed would hit it. The IDE pauses because it hit the breakpoint. I press F10 (Step Over) a few times to step through the code. Then the another thread hit the breakpoint, and the IDE popped me over to that thread. I pressed F5 (Continue). The second thread continued processing, and the yellow debug-line returned to my original thread.

Step Through Visual Studio On Click

I am trying to work on this website and I am a bit new to Visual Studio and whatnot. I would like to have a step through action whenever I click on certain icons on the website. Basically it is a lot of code, most of which I am learning, and I need to know where I am sending control when I click certian icons.
Any tips?

Insert break points in your code (click the left margin in the code windows). Your application will then stop, and you'll be sent to Visual Studio to do stuff when the code hits the break points. You also have functions to go through the app line by line from a break point when VS is in debug mode.

Well, the Button that you click must have a Click Event Handler in the code behind file. You can go to that code and add a break point by pressing F9 key or use Debug > Toggle Breakpoint, which makes debugger break when that line of code is executed, after which you can use F10 key or use Debug > Step Over to move debugger to next line after executing the current line. While debugging, you can use mouse hover to know values of variables.

Editing code in Visual Studio 2008 in debug mode

I am curious to know if there is a way to edit code in C# VS 2008 right when it has hit a breakpoint and I am walking thru the code... can I modify the code (such as the value in a variable or if my stepthrough line is about to hit an if statement ... can I modify the if statement....etc)?
So far, I have to stop running VS, modify the code, then hit F5 and wait till the breakpoint is hit again.
When the breakpoint hits, and I am walking thru the code, and I attempt to edit the code, I get a message "Changes are not allowed when the debugger has been attached to an already running process of the code being debugged was optimized at build or run time."

There are only a few reasons I know of why Edit+Continue would be disabled in the Debug build. First and foremost is a 64-bit operating system, E+C only works for 32-bit code. Fix that with Project + Properties, Build tab, Platform Target = x86.
It is also an option that might have been turned off. Tools + Options, Debugging, Edit and Continue, Enable checkbox.
If this doesn't help, tell us a bit more about the kind of code you're debugging, the project template you selected when you started the project, how you got the debugger to break and a stack trace copied from the Call Stack window.

Yes, you can.
This is called Edit and Continue.
Note that it has some limitations.
EDIT: You need to switch to a debug build.

To modify the value of a variable or set a property while in break mode go to the Immediate window, set the new value, and hit return e.g.
strValue = "newValue"
Calendar1.Enabled = true
To retrieve a value you can just print it to the window e.e.
?strValue
?Calendar1.Enabled

Stop running your app.
Go to Tools > Options > Debugging > Edit and Continue
Disable “Enable Edit and Continue”.

In response to this question:
can I modify the code (such as the
value in a variable or if my
stepthrough line is about to hit an if
statement ... can I modify the if
statement....etc)?
You cannot pop a new value into a variable directly, but what you can do is this:
Set a breakpoint
When that breakpoint is hit, click on the arrow in the left margin and drag it up to a previous line
Now you can add code to change the circumstances (for example, you can set a variable to a new value, add/remove items from a collection, etc.)
See the other answers about enabling Edit & Continue -- in particular, make sure you're in Debug mode.

To solve this problem I did the following...
BUILD > CONFIGURATION MANAGER
Active solution configuration: DEBUG
project context configuration: DEBUG
then TOOLS > OPTIONS > DEBUGGING > EDIT & CONTINUE
make sure edit & continue is selected
then BUILD > CLEAN SOLUTION
then BUILD > REBUILD SOLUTION
Then start debug, then pause, then your code should be editable

Below answer worked for me :
http://whyiamright.wordpress.com/2007/12/20/aspnet-edit-and-continue-in-visual-studio-2005/
The second point says - project-properties-web-> enable edit and continue.
thats it.