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
Related
I've switched over to using the new Modules in Visual Studio (2019 - 16.10.4). Everything compiles and runs just fine if I do a full compilation (i.e. Clean the solution first). Very often when I compile normally, though, I get a crash or initialisation. The error is Application Error (0xC0000005) and appears on startup.
In x86, there's no valid call stack to look at at all. In x64, the debugger points to a valid call stack, at exe_common.inl in a line that says __scrt_current_native_startup_state = __scrt_native_startup_state::initialized;. I realise that's a red herring, and the actual line is _initterm(__xc_a, __xc_z); which I understand is the global memory initialisation.
Is anyone aware of such issues with Modules in VC? The internet doesn't have much information on this case, which leads me to believe it has to do with various configuration options that I might be using. Any pointers? I'm really hoping I won't have to stop using Modules, which I was really looking forward to. There is also a slight chance a recent update to Visual Studio or perhaps something obscure I might have done in the conversion to Modules that is the culprit.
It's just strange that it's guaranteed to work with a full compilation, which would lead me to think that the compiler is to blame.
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
I have an embedded project which runs on a 68332 processor target (68k family). There is no OS on the target. We have a custom simulator that will allow our code to execute within Windows. The simulator is completely without our control to modify. Basically the simulator is executing the machine code which isn't very good when you need to debug. What I would really like to do is interface a debugger to allow us to debug at the source level rather than at the machine/assembly level. Has anyone ever done such a thing? Is there a spec that debuggers support? Perhaps would something like gdb work for this? Any advice is appreciated.
This is not necessarily an answer to your question - I'm not familiar with hooking up an existing 3rd-party debugger to a program executing inside a VM so I can't advise about that.
However, you control the source of your simulator so you can try implementing an interface (maybe a local socket, etc.) where your simulator keeps reporting status information about the code that's executing and links it up with source files by reading debug information from some generated debugging database. You'd likely have to support reading the debugging format of the compiler that compiles your 68k code and then use that information to link back assembly instructions to source code lines.
This way you're effectively implementing a debugger, but since you already have the simulator (a VM really), that's probably not too much of extra work - the simulator already has all state information about the executing 68k code, you just need a way to temporarily pause execution and extract state information during pause. Stepping through code after that is probably a trivial repeat of these steps.
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.
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.