How to avoid a serious error in .NET CF 3.5 and CE 6 R3

Question

When i start this sample program on the device with an attached debugger a serious error occurs.

This is a stripped down version of what happens in our real application.

What i found out is:

Debugger must be attached
Memory must be filled somehow (I think this will force garbage collection)
Garbage (bitmap)objects must exist. Other Objects might lead to the same error
A form must be shown (No difference if Application.Run() or ShowDialog is used)

Then when the form is visible and the GC collects the bitmaps a serious error occurs.

I'm running WindowsCE 6 R3 with .NET Compact Framework 3.5.

static class Program {

    static void Main() {
        // Fill up memory - Depends on device
        var memory = new int[100000 * 150];

        // Settings the priority higher will raise the error earlier.
        // With Priority set to Normal the EXE won't get freed correct.
        // Without this line i have to reboot the CE after every test run...
        Thread.CurrentThread.Priority = ThreadPriority.Highest;

        // 80 is just random choosen. The error occurs also with 30 Bitmaps...
        for (int o = 1; o < 80; o++) {
            // Create a Bitmap and don't free it manually. The
            // The garbage collector will take care of it :)
            var bitmap = new Bitmap(100, 100);

            // When i dispose the Bitmap, everything works fine...
            //bitmap.Dispose();
        }

        // Force a GC run
        System.Diagnostics.Debug.WriteLine(GC.GetTotalMemory(true));

        // Then error occurs when the form is shown.
        System.Windows.Forms.Application.Run(new System.Windows.Forms.Form());
    }
}

I've already found similar questions but no anwser...

What i've tried so far:

Clean all resources manually. I've already searched all bitmap creations and disposed or cached them. The error still occurs, it's not only the Bitmaps that are bad...

isn't your own comment the solution? "When i dispose the Bitmap, everything works fine..." — Sayse, May 03 '13 at 10:35
The problem is that bitmaps are not the only types that will let the error occure. I've fixed all bitmap references in our real application => the error still occurs. I think there are more types than only the Bitmap i need to take care of. How do i find out which types are "bad"? Checking all IDisposables in the whole framework? — Benjamin, May 03 '13 at 10:40

score 1 · Answer 1 · answered May 05 '13 at 17:29

1

I have a theory, and that is that the system is swapping. If the debugger tries to retrieve the content of a variable who's own size exceeds CE's paging pool size, I could imagine this to deadlock. The debugger stopped the system to read the data, but the system can't provide the content because it can't swap in the data. Using IOCTL_HAL_GET_POOL_PARAMETERS, you should be able to detect whether the system is swapping or not.

answered May 05 '13 at 17:29

Ulrich Eckhardt

16,572
3
28
55

Sounds interesting, i'll investigate this and let you know the results. – Benjamin May 06 '13 at 08:04
1

Did found a link that confirms your theory: http://support.microsoft.com/kb/946201/en-us. Need to rebuild the os to test it. – Benjamin May 06 '13 at 12:15
ok, did not work. i disabled the paging and the error still occurs. – Benjamin May 07 '13 at 05:19

score 0 · Answer 2 · answered May 03 '13 at 16:28

This is hard to point an answer for this.

When you say, a serious error occurs, my guess is you are seeing an OutOfMemoryException.

The Garbage Collector (GC) runs as the Framework allots time to the GC or calls it.

If you are creating/using memory faster than the Framework is able to call the GC, you could run out of memory - especially in a CF application.

The MSDN link above says the following:

The .NET Framework's garbage collector manages the allocation and release of memory for your application. Each time you use the new operator to create an object, the runtime allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. However, memory is not infinite. Eventually the garbage collector must perform a collection in order to free some memory. The garbage collector's optimizing engine determines the best time to perform a collection, based upon the allocations being made. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations to reclaim their memory.

To get around this, you would need to release the resources as you are finished with them. If you need that data at some later point, you could save the resource to some sort of media (flash data, hard drive, etc.) for retrieval later.

For more on this, you can read Steven Pratschner's blog entitled An Overview of the .Net Compact Framework Garbage Collector.

How to avoid a serious error in .NET CF 3.5 and CE 6 R3

2 Answers2