In C#, VS 2010, is there a keyboard shortcut to see from where did the breakpoint was hit when you debug?
For example, if I have a breakpoint in a method called myMethod(), and it was hit, how to see from what line was it called?
You can look at the "Call Stack". In VS go to Debug > Windows > Call Stack.
In debug mode the call stack will show which methods have been called in order to reach your break point.
If you open up the Call Stack window you can see the chain of method calls leading to the current line.
If you've got one of the fancier versions of Visual Studio, you might also take a look at Debugger Canvas.
Isn't the call stack window enought ?
You can look at the call stack which will show you where the method call came from, it can be opened by going to the Debug => Windows menu option when your app is running or by pressing Ctrl+D,C.
Are you looking for the entire call stack?
In this case you may try this when your breakpoint is hit:
- On the Debug menu, select Windows and then click Call Stack.
In simple cases the "Call stack" Window will show this.
If the compiler used tail call optimization or method inlining, it can give an unexpected result. But that shouldn't happen while debugging, because that (by default) disables those optimizations.
yield-iterators and async methods show from where they were resumed, and not where they were originally called.
Related
I'm having a problem in Visual Studio 2012/C# which is driving me crazy. I have a particular line of code in a C# file with NO breakpoint set. Every time this line should be executed the debugger interrupts the execution of my code like a breakpoint was set. The only difference i noticed is the arrow on the left hand side, indicating the current step. Usually this arrow is yellow (when a breakpoint is set). In my case it is grey.
I have been searching for a solution but did not find anything useful to this. I tried deleting all breakpoints, build project, rebuild project, clean project and it still appears.
Does anyone have the same problems and found a solution this?
normal arrow:
arrow in my case:
This line of code is currently executing, it calls something else, e.g. native code or .NET internal code and an exception happens there. You can see both arrows in the call stack window:
Perhaps you need to turn on "Show external code".
If you can't see the exception dialog, usually you can show it like this:
I was wondering if there is any way to return the path that Visual Studio takes when running through a program. For example, without setting breakpoints, is it possible to know exactly what happens when I click a button on a web app I created? Like if I clicked a button that had an action, is there some kind of info that Visual Studio can spit out that tells me what happened? (which functions in which files were used, etc. Essentially the "code path").
To add on to my question, I'd like to use something like this to help debug an issue. I want to know exactly what is happening when I perform some kind of action (button click in my example). If I know every "code path" I can better address the issue I'm having.
If I understand correctly your question, you're looking for Environment.StackTrace
The StackTrace property lists method calls in reverse chronological order, that is, the most recent method call is described first, and one line of stack trace information is listed for each method call on the stack. However, the StackTrace property might not report as many method calls as expected due to code transformations that occur during optimization.
Something else you can do is adding debug log entries to know what's is going on. It may be more useful since you could add extra custom data.
Not sure if you already have a log framework on your project. If you don't have any log4net could be a good option
Converting my comment to an answer so there is an answer that addresses the original question:
Use a performance profiler, which is designed to observe execution paths (typically to help you find bottlenecks, etc., but it will work fine for your purposes too). A good performance profiler will let you dig down and see, for any method, what methods it calls, how frequently, etc.
You can print out a call stack results to the output window in Visual Studio. You will still need to use breakpoints but the ones that doesn't stop the application. To do that:
Find the place in your code when you would like to get the stack printed out. For instance at the end of button clicked handler.
Place a break point there.
Right click the breakpoint. From the context menu select "When Hit..." option.
In the window that will show up select "Print a message:" checkbox. It will enable a textbox. In the textbox type in: $CALLSTACK.
Check the "Continue execution" checkbox if you don't want to stop the execution while printing the results.
I don't remember if the "When Hit..." option is available in the Express edition of Visual Studio.
There are also some other data you can print out without breaking execution, e.g.: previous function, process id, etc. The details are actually available in the "When Hit..." window.
I did some research on this before asking the question and since I might be asking it incorrectly, I might not have done the right searches here first.
What I am trying to accomplish is when I start to debug or run an application in Visual Studio, is to have the IDE show me what methods are executing when I do something in the GUI/application.
For instance if I click a button in the GUI labelled "Search", I want to see the chain of events/methods that execute for this process. This I am not sure of. I hope I have asked the question correctly. Thank you for your time.
Have a try with IntelliTrace.
Make sure IntelliTrace is enabled and call information is selected;
Launch your GUI application, and perform what action you want;
In IntelliTrace window, click Break All. If IntelliTrace window is not displayed, click Debug -> Windows -> IntelliTrace Event;
Expand the event you are interested, for example, 'Clicked Search', and click Call View link;
You can see call stack you are interested.
There are two ways to approach this:
If you have no idea where the code you are looking for is, then simply start your program with a Profiler such as JetBrains dotTrace. Then, get ready to push the button, click "Start Profiling", click the button, and then as soon as the operation is finished, click "Get Snapshot". Now, use dotTrace's Call Tree to see which methods called which. I use this technique all the time for just this purpose!
In this view, you can use the arrows key to navigate the method-calls tree.
If you have a general idea of which class[/es] get invoked when you hit the button on the GUI, but don't know exactly which methods are called, you can use OzCode's "Add Breakpoint to Every Method" on a class, so that even if you don't know the exact method that's about to be called, whenever the class is accessed, you'll break into the debugger and be able to explore.
Due Diligence Disclaimer: I am a co-creator of OzCode.
You can use the Runtime Flow tool (commercial, developed by me) to see the chain of events/methods in a .NET application for GUI actions.
I am working in Microsoft Visual C# 2008 on a Windows Form application.
I would like to write some variables out to a window in the IDE to determine what values they contain. I thought perhaps I could write to the console using console.writeline however I did not see where I could open a console window.
Is there a command I should be using to write to the immediate window or some other place where the information can easily be seen in the IDE?
Use Debug.WriteLine(). It's output goes to the Output window. Console.WriteLine() works the same way in a Winforms app but using Debug is better since that code automatically gets removed in the Release build.
And of course, you'll want to leverage the debugger first.
You can use Trace also, which has more features:
http://msdn.microsoft.com/en-us/library/4y5y10s7.aspx
Trace.WriteLine("Error ")
If you just want to see what the current value of a variable is, put a breakpoint in your code somewhere where this variable is referenced (a breakpoint is a red dot that will appear if you click on the left side of your code window).
Then just run the program, and when your breakpoint is hit the execution will suspend right on the breakpoint. Just hold your mouse over the variable and the popup will show you what the value is.
You can use the Spywindows in debug mode.
Console.WriteLine() writes to the standard output stream. while Debug.WriteLine() writes to all trace listeners in the Listeners collection, it is possible that this could be output in more than one place (VS output window, Console, Log file)
1) Use Debug.WriteLine to output to the debug window in DEBUG builds.
2) Use Console.WriteLine when you need to output to a console (unless it's a console application it also outputs to the debug window)
3) Use Trace.WriteLine to output to the output window in all builds. It's output can also be seen when running Mark Russinovich's (formerly SysInternals) Dgbview, which allows you to look at trace statements in a running process (without any debugger attached).
4) Use a trace-point: put a break-point on the line of interest, right-click the red bullet indicating the break-point, choose "When hit..", check "Print A message" and in the window type something like "The value of x is {x}" where x is your variable. The expression in the curly braces will be evaluated for output. This can be useful when you don't want to edit your code.
So my C# program is quitting/disapearing/closing/crashing suddenly even in debug mode.
How can I make it break/pause/stop so as to find out where caused it?
Set a breakpoint (by clicking the left of the line numbers--it's a red circle) that you know is before the point where it crashes and then step through it (using F8). The last statement that you're on is the one that it's crashing at.
If you're in Visual Studio you can enable "Stop when an exception is thrown" - go Debug->Exceptions. This is often quite useful for detecting the exact source of the problem.
You may be able to learn more by using an unhandled exception handler. However, if you're in debug mode you should be able to see it by default. Check your Debug: Exceptions settings to make sure you haven't accidentally stopped reporting them in debug mode.
as Eric suggested try going through step through it... also always place try/catch in your end caller apps in order to manage exceptions.
Also, it may be worth checking your code for occurrences of Environment.FailFast, just in case someone tried to be (too) smart.
You can hit F10 to start debugging your project. This will put a breakpoint right at the beginning of your Main method, then you can go from there stepping through the code with F11 to see at which points it crashes.