C# application terminates for no reason

We have an issue where Visual C# GUI Application terminates with no reason.
We are using the Colibri T30 on a Colibri Evaluation Board; the same also happens on an Iris board.
Originally we thought it was to do with sound, or GPIO, or the use of the serial I/O, but when we stop using those in turn the issue and becomes less frequent, but still occurs.

It seems to happen whilst the application is being debugged (from VS professional 2008) via USB; it may not happen when the application is running directly on the target.
We are experienced with C# on this platform and have tried many things (commenting things out, putting in breakpoints, catching exceptions), but have been unable to narrow down the issue.

There is apparently no information at all about why the application might be exiting:

The messages we get on the Visual Studio C# window show:
HWDriver::uartAgent_MessageReceived State=Armed message: active
SoundsPlayer::MachineStateChanged. New State=Active
The program ‘[0x6590106] PrimaryProcessor.exe: Managed’ has exited with code 0 (0x0).

This is a serious issue for us because we are making no progress.

Can anyone help with thoughts about how to go about debugging this?


This is a known issue debugging with Visual Studio and C#/C++. To my understanding there are some unstability in the debug part of Visual Studio. So it is actually a Microsoft issue.
Try using ethernet (if possible) for debugging instead. It will be much more stable than USB debug.



We had a similar issue and, in our case, it was related to this:




Managed application crashes with debugger attached on ARMv7

If your managed application consumes more than 32MB on an ARMv7 platform you may run in to problems when debugging with your application crashing. Typically the application runs fine when launched on the device, but when launched from the Visual Studio debugger the application will crash as soon as the stack consumption goes above 32MB. This hotfix describes the problem better than I can:


You do not need to apply the hotfix to WEC7 as PB will have already placed the fixed .netCF assemblies on to your image, however you will need to add the registry value to activate the fix: