WinDBG integration, 3rd party Diff viewer

[mitcheljh]

Integration with WinDBG.
(As long as it wouldn't be an overwhelming project, and wouldn't have any negative side effects).
This would just be a "Nice to Have" though, certainly not essential.

Another thing I always wanted, is the capability to use a 3rd party diff viewer.
Although DIFFzilla is very good, I'm really partial to Beyond Compare.  I was able to hack Diff.e so SE would use Beyond Compare instead of DIFFzilla, but there's a few small issues with the hack.  Having the option in SE to substitute the diff viewer of your choice, where it would work in all cases, would be really nice.

[vivitron]

Support for mdbg http://msdn.microsoft.com/en-us/library/ms229861.aspx or WinDBG with the SOSEX extension.... http://www.stevestechspot.com/SOSEXV40NowAvailable.aspx so that managed applications could be debugged directly with SE.

That's the only reason I still use VS.

[vivitron]

Really... if there was a way to:

• Automatically perform a series of commands on WinDBG startup (i.e. load SOSEX extension)
• Customize the commands for setting break points and getting info (SOSEX uses custom commands so that it can map to the jit'd code)

Then we could roll with the current implementation of SE/WinDBG. I currently can do it by hand, but it would be much easier with a integrated interface.

So... if you could specify the params for setting breakpoints, etc, then it would make the current implemented much more flexible.

i.e. to set a breakpoint with a c# file and sosex in windbg:

Code: [Select]

mbp       <SourceFile> <nLineNum> [ColNum] [Options]     Sets a managed breakpoint at the specified source code location
Or to display information about a type or variable:

Code: [Select]

mdt       [TypeName | VarName | MT] [ADDR] [Options]     Displays the fields of an object or type, optionally recursively
This might be a crazy idea, but seems like it has alot of potential and would make SE a full .NET developer tool.

UPDATE: I looked around at the debug code today and still think it's possible.

Here is my list so far:

• Add a "isManaged" config option
• If isManaged, then use custom commands for debugging vs the external hooks that are used in debug.sh
• Automatically run debug_send_command .load c:\system\sosex on debug start (assuming sosex is loaded in c:\system)
• Change debug_toggle_breakpoint to use the filename and send !mbp file_path(p_buf_name) p_RLine to enable the breakpoint
• Change debug_find_and_probe_breakpoint to lookup breakpoints via the !mbl command
• Not sure where the symbol information comes from... Need to use !mdt command to look that up...

Support for mdbg http://msdn.microsoft.com/en-us/library/ms229861.aspx or WinDBG with the SOSEX extension.... http://www.stevestechspot.com/SOSEXV40NowAvailable.aspx so that managed applications could be debugged directly with SE.

That's the only reason I still use VS.