When I open a dump file, in VS2012, I see two options for debugging: Debug with Mixed and Debug with Native Only. I am wondering what these two options mean, and what the differences are between them.
I tried searching Google for documentation/etc. but could not find anything on these two options, and the closest that I came was finding a few posts where people said they used Debug with Mixed but didn't say why, and one post that noted that Debug with Native Only displays only for .NET 4.0.
Whether you choose Debug with Native Only or Debug with Mixed or Debug Managed Memory, depends on what your dump file is of.
Debug with Native Only: For native apps (it will allow you to see the callstack and source code from the native part of the app),
Debug with Mixed: Allows you to see the managed source code part as well.
Debug Managed Memory: Useful for debugging memory problems in managed code
Some links that might prove useful:
http://blogs.msdn.com/b/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx
https://msdn.microsoft.com/en-us/library/vstudio/d5zhxt22.aspx#BKMK_Open_a_dump_file
http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/20/using-visual-studio-2013-to-diagnose-net-memory-issues-in-production.aspx
http://blogs.msdn.com/b/visualstudioalm/archive/2013/10/16/net-memory-analysis-enhancements-in-visual-studio-2013.aspx
http://blogs.msdn.com/b/visualstudioalm/archive/2015/01/05/understanding-symbol-files-and-visual-studio-s-symbol-settings.aspx
Related
If I try to deploy and debug my windows 10 mobile app, the debugging stopped with error:
It only happens when I set Native debugging. Managed debugging doesn't cause such error.
It is stated here that .NET Native debug engine has some capability differences from normal .NET debugging. Furthermore, it is recommended to debug a non-optimized code:
These optimizations will have a significant impact on the debugging experience including unpredictable stepping and breakpoint behavior (due to code inlining) and the inability to inspect most variables due to memory optimizations.
Although this was not your presented case, it still pushes further to the following practical solution:
This means you will want to debug a non-optimized .NET Native build. This fastest way to do this is simply to disable optimizations.
Source
How to debug mingw built binaries to detect heap errors? I see there are several questions on the topic, but they are general and it's hard to find the tool that would work well with MinGW. I spent much time on finding the solution, I hope the combined topic will be helpful.
Such a tool becomes necessary when for example someone reports a bug in your library while running it under Visual Studio debugger, which stops with a "Heap Error".
There is a tool provided by Microsoft called Application Verifier. It is a gui tool that changes system settings to run selected applications in a controlled environment. This makes it possible to crash your program if it causes detectable memory errors. This is a controlled crash that can be debugged.
Fortunately it is obtainable from Microsoft as a separate download. Another way to get it is to have Windows SDK installed with checked Application Verifier checkbox. SDK offers also an option Application Verifier redistributable.
After you configure Application Verifier to have an eye for your app, you need to debug it. Debugging under MinGW is a more common subject, already explained on stackoverflow. [mingw] [debugging] query on stackoverflow gives interesting articles. One of them is How do I use the MinGW gdb debugger to debug a C++ program in Windows?. Gdb is the one I used.
The general questions How to debug heap corruption errors? and Heap corruption detection tool for C++ were helpful to find this tool, but I wasn't sure if it is compatible with MinGW. It is.
Where can I find msvcrtd.dll (the debug CRT), corresponding to \WinDDK\7600.16385.1\lib\Crt\i386\msvcrtd.lib in the Windows Driver Kit?
Having the same DDK on my system, I cannot find the file , however, you can do it with some tools or programatically:
if you are using a program thats loading that dll, you can use windbg to display the module info (which should include the path), else you can use one of the psapi functions.
After some poking around, it would seem from this article that there is no longer a public msvcrtd.dll to use with the WDK, it does however give some advice on using alternatives. MSDN also supports the fact that there is no longer a debug CRT, as there only methods for debugging involve the debug API and/or WinDBG. However I suspect that the dll might be available from a checked build of windows.
Seems like it's not distributed.
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.
When I'm debugging something in Delphi and there's a system library in the stack trace, I've got the name of the library and the function that's being called into. Unfortunately, this doesn't seem to apply to any other external DLLs. I've got one that was compiled in Visual C++ 2005, and any time it gives me any sort of trouble, I have to attach the VS debugger and start tracing through the code from the original entrance point, because Delphi gives me no clue what's actually happening.
This DLL was built with VS's debug information compiled into it, but apparently Delphi has no way of reading it. Is there some way to fiddle with the debug options to change that, so I can get meaningful function names in my stack trace the same as I can with system libraries?
Delphi and Microsoft each use their own kind of debug information, and neither can use the other's kind.
These two pages might get you going into conversion:
Debugging symbols/tools using Delphi
Debugging Format Interoperability
But I'd just fire up Visual C++ 2005 and debug the C++ portion there. That is: the opposite of the solution in Stack Overflow question How to debug a DLL file in Delphi.