Windows Mobile Memory Leak Issue

views:

521

answers:

+2 Q:

Windows Mobile Memory Leak Issue

All,

I currently have a phone from a customer who experienced various issue while running our windows mobile application. This issue is that the phone eventually resets completely while running the application. I have this in house to do some testing and I haven't experienced the reset, but I do notice that program memory is dropping significantly while running through the forms. We do have a slight memory leak in out application that we have been trying to narrow down, but nothing to this magnitude.

Eventually the application just drops out of program memory, but it seems as though not all the memory is released. Program memory doesn't go back up to what it was originally. They have installed some third party applications, such as VicSoft ClearTemp, but this applications seems to just remove temporary files to keep the storage memory low. The phones in question are Sprint 6800 Windows Mobile 6.0 profressional. The application is written in the .NET 2.0 Compact Framework.

We do have an issue where the application is dropping out of memory which is still an ongoing issue, and this seems to be happening randomly. THis issue seems to be directly memory related, but maybe the two are working hand in hand causing the crash.

Any ideas or help would be greatly appreciated.

Steve

+3 A:

Make sure you're disposing your forms after you're done with them (calling Dispose() or declaring and using them in a using() block), especially if they contain Bitmaps and/or PictureBoxes. More generally, make sure you're disposing every resource that can be disposed of.

MusiGenesis 2009-09-23 13:27:14

Yes, any graphics related objects (Graphics, Bitmap, Font, Pen, SolidBrush, etc.) should be disposed explicitly, as .NET CF will otherwise not properly dispose them and therefore leak memory.

tomlog 2009-09-23 13:32:38

^^ Apart from the Brushes collection in Full Framework. They get tidied on exit, but they're not in .NET CF so I guess this comment is somewhat redundant. :)

Quibblesome 2009-09-29 14:55:02

@Quarrelsome: the Bitmap is the big killer anyway, *especially* in CF, because in some situations in Windows Mobile they're created in specialized video RAM instead of regular program memory, and in most devices this video RAM is limited to about 4 MB or even 1 MB.

MusiGenesis 2009-09-29 15:17:47

+3 A:

The effect of the app ending is likely being caused by 1 of 2 things:

An unhandled exception (likely an OOM) is causing it to unwind. You should be handling these.
The WinMo platform itself is killing the app via the WM_HIBERNATE message.

As has been pointed out, ensure you are calling Dispose on all GDI-related objects (Bitmaps, Pens, etc). Descriptions of a bug related to Bitmaps can be found here and here.

Anotehr thing to be aware of is that Components on a Form are not Disposed when the Form itself is (unlike Controls, which are). So if you're doing a lot of Form creating and destruction, pay close attention to that.

If you can upgrade the project to target 3.5, even if it's only for internal testing, running the CF 3.5 CLR Profiler can certainly help you find the leak.

ctacke 2009-09-23 20:13:40

Thanks for the comments! I have reviewed all the posts on here. I just want to explain one thing. All of our forms are kept around in memory, as before when we instantiated each form everytime, it was draining even more memory. All the form controls are left as they were previously.For instance, if I have a search screen with one text box for searching name, if I type in "Steve" and leave the form, "Steve" will still be in that textbox next time I Setup the form. Like I said before, we keep these around the entire time.Perhaps this is our issue?

2009-09-29 14:56:04

@Steve: I think keeping all your forms resident in memory instead of creating them and disposing them is a *different* issue that you've run into as an attempted workaround for your deeper problem. There may be scenarios where you need to hang onto a form that takes a long time to initialize, but you definitely do not need to do this for a simple form with a TextBox on it.

MusiGenesis 2009-09-29 15:33:02

@Steve: I agree with MusiGenesis that keeping all forms may not be a great strategy (though I've done apps where it did make sense, so that's a case-by-case thing). The fact that you're not creating more Forms but still running out of memory indicates to me that you are indeed leaking - probably GDI objects. Are you, for example, periodically changing the image in a PictureBox or something like that?

ctacke 2009-09-29 15:49:02

If you're constantly creating and destroying objects ENSURE your event handlers are unhooked, otherwise the Garbage Collector will think these objects are still in use, resulting in what looks like a memory leak.

Quibblesome 2009-09-29 14:53:35

Great solution to Windows Mobile Memory Leak - cleanRAM (RAM Cleaner).

Get more information and download the latest cleanRAM version:

www.htcaddicts.com/?id=110

Ronen 2009-11-08 17:08:13

ansaurus

tags:

views:

answers:

Windows Mobile Memory Leak Issue

related questions