We Keep Coding

C# : catch all errors/exceptions of a mixed managed/unmanaged process

I have a big and complex process that runs on a production environment that's basically a WPF user interface developed in C#. It also hosts threads and DLL's written in C++ unmanaged and managed code.
Typically, if an exception raises, it's caught and the related stack dump is written in a log file for post-mortem debugging purposes. Unfortunately, from time to time, the application crashes without writing any information in the log so we have no clue about who's causing the crash.
Does anybody know how to detect and eventually trace all the causes that make the application crash and are not detected with a simple try-catch block?
To give an example I saw that StackOverflow Exception is not caught and also errors like 0xc0000374 coming from unmanaged code are not detected. This is not a matter of debugging it. I know I can attach a debugger to the system and try to reproduce the problem. But as I told this is a production system and I have to analyze issues coming from the field after the problem occurred.

Unlike C# exceptions, C++ exceptions do not catch hardware exceptions such as access violations or stack overflows since C++ apps run unmanaged and directly on the cpu.
For post-crash analysis I would suggest using something like breakpad. breakpad will create a dump file which will give you very useful information such as a call-stack, running threads and stack/heap memory depending on your configuration.
This way you would not need to witness the crash happening or even try to reproduce it which I know from experience can be very difficult. All you would need is a way to retrieve these crash dumps from your users devices.

You can log exception by subscribing to AppDomain.UnhandledException event. Its args.ExceptionObject argument is of type object and is designed not to be limited by C# exceptions, so you can call ToString method to log it somewhere.
Also check MSDN docs for its limitations. For instance:
Starting with the .NET Framework 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.

Solved ! I followed Mohamad Elghawi suggestion and I integrated breakpad. After I struggled a lot in order to make it compiling, linking and working under Visual Studio 2008, I was able to catch critical system exceptions and generate a crash dump. I'm also able to generate a dump on demand, this is useful when the application stuck for some reason and I'm able to identify this issue with an external thread that monitors all the others.
Pay attention ! The visual studio solution isn't included in the git repo and the gyp tool, in contradiction as wrongly mentioned in some threads, it's also not there. You have to download the gyp tool separately and work a bit on the .gyp files inside the breadpad three in order to generate a proper solution. Furthermore some include files and definitions are missing if you want to compile it in Visual Studio 2008 so you have also to manage this.
Thanks guys !

How to debug an application which suddenly terminates without any feedback?

The application uses Xamarin.Android, which may be a big problem in itself. The problem is that sometimes it just quits (process is being terminated) and there's nothing in the log that can be associated with it. (although I guess that it's related to running out of memory, but I can't yet prove it — according to DDMS, most of the times all is OK, and if Xamarin.Android uses another pool of memory, then I don't know how to measure it)
I've searched the code base for "Environment.Exit" and, of course, didn't found anything.
What are the options for finding the culprit of such thing?

You could try to use the garbage collector by yourself. Just run
Runtime.getRuntime().gc();
The Runtime instance has also a method to read the free memory space. So you could figure out by yourself whether it's a memory problem.
EDIT:
Oh I read that Xamarin uses the C# language. But I'm quite sure that C# has similar methods.

When you say log, are you referring to an application log, or the device log?
When tracking down these sorts of bugs, I've always found aLogCat invaluable.
I open it, clear all the current logs, then use my application up to the point where it crashes. Then I quickly go back to aLogCat, pause it and scroll up to where the error is - it's usually found in the nearest red/orange blocks.
There's a blog post here about how I found attributes left out by the Xamarin linker using this method.

Debug Assertion Failed: C++ exception in a C# application?

I have been managing and updating a particular application. It is old and I am not the original developer. It's suffered through several debugging sessions over the years among other small patches.
It has been running stable for the last couple of months, but then an exception occurred that seems odd to me. Since this only happens on the server ( it is a server application. ) in release mode.
The application is written in C#, is managed in Visual Studio 2012 Professional and is released to be explicitly 32-bit .NET 3.5 since the server is unfortunately running Windows 2003. (I have tried to convince them to update so I can update the application to .NET 4.5. But alas.)
So I am getting a C++ Debug message. See the screenshot below. It occurs in a file named vsprintf.c I am guessing on line 91. The only message that gives me any hint is format != NULL.
This confuses me however. What can possibly cause this? What steps can I best take to debug in a situation like this? What is "vsprintf.c"?
Edit: I managed to find something in eventviewer. I will continue to research this in the meanwhile.
Sincerely,
me.

This is an assertion failure, ie an assumtion that a function you are calling makes is not met, in this case that a pointer is not null. From the looks of it, its a format string. Are you using format strings directly? If so, look there. If not, this is probably a memory leak problem, followed by an out-of-memory malfunction.

vsprintf calls can be caused by sprintf and other derivates, you should maybe check all these calls. (This can also be methods of string classes, as I saw in the VCL).
If the bug isn't caused by one of the libraries you use, then there should be a NULL (or 0) in the format string parameter, which is mostly the last before the ... in the prototype.
If you are familiar with regular expressions, this may help a lot when looking for patterns.

Find out where a multi-threading C# program is stuck

I have written a C# program having some thousand lines and several threads. Execution works fine for several hours/days until the application, which is running on a Windows server, starts to slow everything (other programs/web server) down as it suddenly begins to use up about 50-80% of the CPU.
I assume that it is stuck in some while-loop, but I do not know where exactly. It would already be a help to know which thread uses up the largest share of the system resources. As there is not any exception thrown, I do not see any direct possibility to find out.
The code has already been inspected but I did not find any significant/obvious programming mistakes.
Does anybody know a good way to let Visual Studio monitor the current CPU-load in order to show where it is used up?

Oh, how I love Managed Stack Explorer. http://mse.codeplex.com/ for most versions of .NET and https://github.com/vadimskipin/MSE for 4.0
Point it at your running application, and it snapshots the stacks of each thread. After looking at a few snapshots, you'll work out where the problem is. Oh, the nastiness of the problem I was facing when I first learnt of this. Oh the joy when it let me find what I'd been hunting for days in just a few minutes.

You can use Perfview (http://www.microsoft.com/en-us/download/details.aspx?id=28567) to capture and the analyse ETL traces when this happens.

How to debug random crashes?

we have a dotnet 2.0 desktop winforms app and it seems to randomly crash. no stack trace, vent log, or anything. it just dissapears.
There are a few theories:
machine simply runs out of resources. some people have said you will always get a window handle exception or a gdi exception but others say it might simply cause crashes.
we are using wrappers around non managed code for 2 modules. exceptions inside either of these modules could cause this behavior.
again, this is not reproducible so i wanted to see if there were any suggestions on how to debug better or anything i can put on the machine to "catch" the crash before it happens to help us understand whats going on.

Your best bet is to purchase John Robbins' book "Debugging Microsoft .NET 2.0 Applications". Your question can go WAY deeper than we have room to type here.

Sounds for me like you need to log at first - maybe you can attach with PostSharp a logger to your methods (see Log4PostSharp) . This will certainly slow you down a lot and produce tons of messages. But you should be able to narrow the problematic code down ... Attach there more logs - remove others. Maybe you can stress-test this parts, later. If the suspect parts are small enough you might even do a code review there.
I know, your question was about debugging - but this could be an approach, too.

You could use Process Monitor from SysInternals (now a part of Microsoft) filtered down to just what you want to monitor. This would give you a good place to start. Just start with a tight focus or make sure you have plenty of space for the log file.

I agree with Boydski. But I also offer this suggestion. Take a close look at the threads if you're doing multi-threading. I had an error like this once that took a long long time to figure out and actually ended up with John Robbins on the phone helping out with it. It turned out to be improper exception handling with threads.

Run your app, with pdb files, and attach WinDbg, make run.
Whem crash occur WinDbg stop app.
Execute this command to generate dump file :
.dump /ma c:\myapp.dmp
An auxiliary tool of analysis is ADPlus
Or try this :
Capturing user dumps using Performance alert
How to use ADPlus to troubleshoot "hangs" and "crashes"
Debugging on the Windows Platform

Do you have a try/catch block around the line 'Application.Run' call that starts the GUI thread? If not do add one and put some logging in for any exceptions thrown there.
You can also wrie up the Application.ThreadException event and log that in case that gives you some more hints.

you should use a global exception handler:
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx

I my past I have this kind of behaviour primarily in relation to COM objects not being released and/or threading issues. Dive into the suggestions that you have gotten here already, but I would also suggest to look into whether you properly release the non-managed objects, so that they do not leak memory.