Windows Mobile: How to identify and prevent shared DLLs from occupying address space?

Question

I'm supporting an "old" mobile application on the WM6 platform. We recently had to upgrade to new devices because the old device isn't available anymore. This also meant to upgrade from WM6.1 to WM6.5, and also from .NET CF 2.0 to 3.5.

The main problem with this application is the constant memory pressure (OutOfMemoryExceptions). I did try to fix memory leaks, and also optimized certain code for memory consumption. However, on the new device the whole situation is much worse than on the older. I understand that there is a 32MB virtual memory limit for each process, regardless of how much physical memory is available (interesting read).

I used VirtualMemory.exe and Motorola eMScript to visualize/analyze the 32MB memory slot of my application. This is what the process virtual memory looks like (32MB total, each gray bar represents 1MB, top is the new device, bottom is the old device). Everything to the right of the red bar are third party DLLs (OS, Vendor, ...). We lost another 3MB by switching to the new device.

It seems that the application is suffering the "DLL crunch" problem, where some third party DLLs occupy virtual memory addresses on the right hand side (highest addresses). Note: The blue bar on the left is occupied by the .exe, I was able to eliminate that using this awesome trick.

So here is my question: How can I identify what DLLs are occupying my address space? I tried eMScript which gives a list with all DLLs and theire addresses, but not the ones on the right of the red bar (shared DLLs). And are there any general recommendations or hints on how to reduce this amount of lost address space? Someone recommended to use a "reduced graphics driver", but I'm not yet convinced this would be addressing the right issue.

The new device is Motorola MC65, in case this is relevant.

Answer 1

To improve the memory available to .NET CF applications, you can implement the trick explained in the article MemMaker for the .NET Compact Framework: moving all your managed code out of the EXE into DLLs. This can help your free some memory in your 32MB slot.

Other relevant articles are Slaying the Virtual Memory Monster:

• Part 1
• Part 2

Answer 2

great question and information. See my > notes.

"...How can I identify what DLLs are occupying my address space? I tried eMScript which gives a list with all DLLs and theire addresses, but not the ones on the right of the red bar (shared DLLs)."

Try to find a copy of devhealth. It is a MS tool to list all DLLs and there addresses and references. See also http://www.hjgode.de/wp/2009/05/27/managed-application-suddenly-fails-to-invoke-dlls/

"And are there any general recommendations or hints on how to reduce this amount of lost address space?"

Some of these DLLs are loaded by drivers and background processes. You may 'eliminate' some of them by disabling the start of the one or other application. But I fear most fo them are needed by the device/OS. In general the memory situation on a WM653 device should be better than on a WM61 one. MS added some additional 'memory savers'. But new OS also comes with new functions and services and so the 'memory enhancemnt' is less than possible. If you can not remove drivers/apps, you should split your single application into several processes. For example, if you have a photo taking function using the camera then split that into a separate application and it will get it's own 32MB process slot.