I've been doing some MSIL work and have come across references to these three debuggers.
What's the difference between them?
Is one of them better than the others wrt. functionality?
Are there others that I have missed?
I'm assuming you meant DbgClr not Clt and mdbg not mdbug?
DbgClr uses the VS shell so you get a nice GUI.
mdbg is the command line managed debugger.
cordbg was an old sample that sorta shipped, but now it's just a wrapper for mdbg. http://blogs.msdn.com/jmstall/archive/2005/11/07/views_on_cordbg_and_mdbg.aspx
Visual Studio is one you missed, but DbgClr should have the same functionality. http://blogs.msdn.com/andypennell/archive/2005/02/21/377621.aspx.
You can also use windbg with SOS extensions to do managed debugging from Windows debugger. SOS is also helpful when using VS since it lets you inspect memory and so on.
To see source level MSIL debugging, try using ilasm with the /debug option. Last time I checked, VS will let you step through the .il source just like C# or any other language.
MSDN blogs have a ton of content about debugging .NET apps -- I suggest you search further there.
Related
I've been using trace points on C++ functions of interest to build a dynamic call graph in Graphviz. The syntax I'm using in the Breakpoint UI to do that is
"$CALLER" -> "$FUNCTION";
Unfortunately, the output isn't quite what i need, because while $FUNCTION expands to the full signature, $CALLER does not. Is there a way to get the signature of the caller in the same format as $FUNCTION? Without that, the node names on my call graph don't match. (I can get around that by removing the signatures for the callees after the fact, but that merges calls to overloaded functions, and isn't ideal.)
In VS 2010, there was a provision for invoking a macro when a breakpoint was hit. Is there a replacement for that in VS 2012 now that Macros are no longer supported?
Or is there a much simpler way to get this information? (I have the Performance Wizard, but I didn't think it had the same fidelity as the debugger, since it uses CPU sampling. And Intellitrace isn't supported for C++, so even if I had the Ultimate edition it wouldn't be an option.)
Thank you.
A good way to collect this information with Visual Studio is to use the Visual Studio Profiler in 'Instrumentation mode'. For more information, refer to MSDN.
You should be able to configure the profiler to collect the entire call-graph and C++ collection is supported.
I am converting several modules from OCaml to F#. To hunt bugs and verify some of the finer differences I am running both versions against the same test case at the same time.
For F# I am using the Visual Studio debugger and for OCaml I am using ocamldebug. Since Visual Studio is a GUI and ocamldebug is a command line, making the comparisons requires more attention than back and forth visual scanning.
I was wondering if there is any OCaml IDE that supports a GUI debugger with stepping while showing the source line highlighted and separate window to display values.
EDIT
I did some more looking after Jack posted an answer and then remembered why I didn't pick one a few months ago when I did this.
The reasons I am passing on the ones I find and staying with the OCaml command line tools are
The command line tools come with the compiler, so they are current and work. There is some documentation on the tools, but honestly I did have to spend a few hours writing my own ocamldebug manual with examples to become proficient with ocamldebug.
They rely on EMACS. It's not EMACS but me; I just hate the way it works. Also all of the tools working with EMACS I found they are just wrappers around ocamldebug. So nothing gained but more memorization of commands. Note: EMACS is actively maintained and updated.
They rely on Eclipse. I have used Eclipse a lot for working with ANTLR, but I only make a system every few years and have very good notes on it so it is worth my time. Once I get Eclipse working for a major ANTLR release, I don't update it again for years. For the small amount of time I plan on debugging OCaml, the cost is too high. Note: Eclipse is actively maintained and updated.
They don't do debugging. Since there are so few GUI tools for OCaml, even an enhanced editor is a benefit for some. Not for me at this time.
The tool/plug-in has not been maintained for some years.
This not a put down of OCaml, just the details as I find them. I don't have a problem with OCaml, I just wish I was more productive with it.
I think most people are just using the OCaml debugger (ocamldebug) from within emacs (see the bottom of that page for details).
I don't know if it supports debugging (yet), but the TypeRex OCaml Programming Studio looks like an interesting project.
Finally, there are some old, unmaintained Eclipse plugins you could try (e.g., Camelia), though I suspect they've bit-rotted for too long to be of much use at this point.
I was unable to find an OCaml GUI debugger with the same ability as Visual Studio using F# that meet my requirements.
If someone does find one or creates one and post that as an answer I will gladly give them them accept vote.
I was wondering if there is any OCaml IDE that supports a GUI debugger with stepping while showing the source line highlighted and separate window to display values.
I'm only just getting back into OCaml and Linux now after a 4 year break but, last I looked, Linux had very poor GUI libraries and OCaml had very poor interoperability so nobody ever got very far writing non-trivial GUI applications in OCaml.
After Google the issue i found that it was reported already but nothing useful yet from MS. I wonder if any one found a work around it?
Another option is to use windbg. You'll have to do a lot of commands by hand, but it's the best debugger out there. It handles mixed mode without any major issues. It has a bit of a learning curve, but it's very versatile.
Visual Studio's debugger is really not reliable when debugging mixed mode applications. Taken from my answer here #5965771:
If you're trying to debug a piece of native code try to use a native project as the debugger start-up application. Under the project settings, "Debugging" tab set the "Debugger Type" to "Mixed", for us this helped sometimes (the native project can be a DLL for example, simply set your main Exe as debugging target in the project settings);
OR, as already mentioned in another answer: Use WinDbg! With it you can debug both managed/unmanaged mixed code applications much more reliably.
use a different debugger, or don't use the debugger at all, just trace to a file or insert breakpoints in the code with inline assembly language.
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
I've inherited a ASP/VB6 code base (not my forte... yet) and I'm trying tease it apart to figure out the cause on an error message I'm receiving when running the app.
I've traced it back through an event that is being raised in on of my classes. Is there away in windows I can search the bulk of the code base for where it is being consumed?
Ctrl-F (and selecting Current Project) has not sufficed.
The linux geek in me is saying dump it to a insert distro box and just grep for the sucker. But there's got to be some way in the IDE to do it... right?
But there's got to be some way in the IDE to do it... right?
No. There are some plugins for the IDE, such as the MZ Tools that might help. Otherwise, just use the find tool from the Windows command line. Not nearly as comfortable as using grep, of course.
If you have any new version of VS (2003,5,8) installed, just use the "Find in Files" feature and point it at the VB6 folders.
Other than that, most "notepad" replacements (textpad, notepad+) offer a "Find in Files" as well.
Check out http://www.mztools.com/index.aspx
MZ-Tools 3.0 is a freeware add-in for Visual Basic 6.0, Visual Basic 5.0 and the Visual Basic For Applications editor.
It is essential for anyone still working with VB 6.0
It has an enhanced find feature as well as a calling Procedure similar to .net Find usage.
I have a large legacy code-base in VB6 which needs maintenance from time to time and I have used Microsoft Desktop Search on my local copy to help find variable and method names across the code files.
Also Grep is available for Windows.