That's awesome-sauce stuff. Imagine if you could have that with native code and you could drill the stack with source all the way to upper layers of win32/ntdll with up to date source (like MS would open some of the win32 source for debugging like they did for WinForms). I don't really see what MS would lose by doing that, the black hats probably have seen the leaked source codes already and don't need it to hack the OS.
That's really nice, although I really need ultimate version? I only have pro.
I'm more of a managed kind of guy. I havent had my coming out as a C++ developer yet, maybe when I turn 45ish and ponder if .Net is really the way to go, maybe then I can come out of the closet. So I've no idea what it would be like to debug this in native
All kidding aside, what would be the advantage of that? You kinda just want that stuff just to work? Why would you want to see it?
Your addin creates a ToolWindow that hosts a WPF user control ( which in turn contains a Canvas ).
The OnEnterBreakMode event handler accesses the Debugger.CurrentStackFrame from the DTE2 application object:
var sf = _applicationObject.Debugger.CurrentStackFrame;
From the StackFrame you get a collection of Expression from the Arguments and Locals collections:
foreach (var item in sf.Locals)
if (item is EnvDTE.Expression)
var exprItem = item as EnvDTE.Expression;
Hooking up to the code on the call stack I assume is done with Project Roslyn.
Working with the values of the variables is a bit limited in my experience. The Expression object.Value property only returns the ToString( ) contents of an object and its members.
So unfortunately as it turns out this only works with managed code. It does not look like this is an open source project either.
Steve, do you think your technique above will also work with unmanaged code? And will it work in non-Ultimate versions?
While the Debugger Canvas plugin is impressive, its feature set is actually quite limited (there are some bugs too - at some point I could no longer switch/close tabs anymore). I wonder how complex such a project would really be if done from scratch.
@Maddus Mattus: There may be other advantages but I'm primarily interested in ways in which it could ease diagnosing app compat issues. Imagine if you were debugging some old dll without the source and didn't even see what OS apis it called - well just seeing those OS api calls gives many clues. Now if it's some broken behaviour, you have to digest the API doc and study error codes and such things - if you could just drill down the commented source, you'd have the documentation right there (as the source) rather than having to go back and forth reading the docs and studying error codes. I'd much rather just step through the source code than translate MSDN docs into code in my head first. This might also help malware analysis and understanding the logic of the API without hoping to find "Old new things" blog about it.
Whether it would ease debugging in windbg for those scenarios where there might be a real OS bug, hard to say, as I try to avoid that since there's no source.
Also - do above justify the cost of enabling that? If there were just positives then maybe, but there's also potential negatives - like even if there were disclaimers and color coded source for the opened API source, some people might look for opportunities to take dependencies on some particular behaviour which might change in future or find bugs and exploits. I can't really answer this.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.