Reputation: 120
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:
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:
Upvotes: 4
Views: 1844
Reputation: 17434
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.
Upvotes: 1
Reputation:
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.
Upvotes: 0