windows-mobilecompact-frameworkvirtual-memorywindows-mobile-6.5

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

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.

virtual memory map

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.

Solution

  • 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: