If I set a breakpoint on a method, how can I see what called the method, when the breakpoint is hit in visual studio 2008?
views:
197answers:
5
+7
A:
Check the Call Stack window (Debug, Windows, Call Stack). Double clicking each entry there will take you to the calling statement. You can also right click on it to enable/disable showing external code items and calls from other threads.
Mehrdad Afshari
2009-08-05 21:22:16
It only has a single entry: where the breakpoint is.
Ronnie Overby
2009-08-05 21:23:09
Are you sure it's not the entry point?
Mehrdad Afshari
2009-08-05 21:24:52
It's not the entry point.
Ronnie Overby
2009-08-05 21:27:46
This is the general way to do it. Unless the method is inlined (which is weird if it's a debug build), there should be something problematic in your specific case.
Mehrdad Afshari
2009-08-05 21:29:06
What do you mean inlined?
Ronnie Overby
2009-08-05 21:30:44
Inlining is an optimization in which a method call is replaced by the body of the method called.
Mehrdad Afshari
2009-08-05 21:31:53
I'm not sure if inlinig is used in .NET.
Roman Plášil
2009-08-05 21:33:08
JIT optimizer does inlining in .NET. It doesn't do that for debug builds or when you are running from a debugger (it does if you attach the debugger after launching a release build with optimizations on.)
Mehrdad Afshari
2009-08-05 21:42:18
It just started working. I don't think I changed anything. I now have 3 more things in my call stack window that shows the path of execution. Thanks
Ronnie Overby
2009-08-06 03:32:11
+1
A:
When the breakpoint is hit, you can view the entire call stack. You can bring that window up by going through the Debug menu->Windows->Call Stack.
You can also bring it up by the shortcut Alt+Ctrl+C
EDIT: You can also right-click on a function name, and view the "Callers Graph", which will show you all the callers for your method. Alternatively, you can bring the Call Browser (by going to View->Other windows->Call Browser ) and search for your method's name.
Umsd
2009-08-05 21:25:18
+1
A:
If you can't see anything in the Call Stack window, then there's definitely something wrong. I would suggest the famous sequence of R-actions:
- Retry
- Recompile
- Restart
- Reinstall :)
Roman Plášil
2009-08-05 21:34:03
+3
A:
If you can't see anything in the call stack at a user-set breakpoint, it generally means it was called from native code.
Another case where it can't get a stack: You hit Debug>Break All and the main thread is in a wait/sleep state, the debugger can have problems building the call stack. I believe the debugger uses the main thread for its implicit function evaluation.
Try attaching (or launching) the mixed-mode (native & managed) code debugger and see if that straightens it out.
280Z28
2009-08-05 21:47:18
+1
A:
Is the break point in a function that is raised by an event? In that case, you might not have a direct call stack back to the caller, and will need to enable viewing all code, and not just "just my code".
Miki Watts
2009-08-05 21:53:33