Windows Mobile: How to Define and Prevent Shared DLLs from Address Space?

Question

I support the "old" mobile application on the WM6 platform. We recently had to upgrade to new devices because the old device is no longer available. It also meant upgrading from WM6.1 to WM6.5, as well as from .NET CF 2.0 to 3.5.

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

I used VirtualMemory.exe and Motorola eMScript to visualize / analyze the 32 megabyte memory slot of my application. This is what the process’s virtual memory looks like (total 32 MB, each gray bar is 1 MB, the top one is a new device, the bottom one is an old device). All that is to the right of the red bar is third-party DLLs (OS, vendor, ...). We lost another 3 MB by switching to a new device.

It seems that the application suffers from a problem with the "DLL crunch" when some third-party DLLs occupy the virtual memory addresses on the right side (the highest addresses). Note. The blue bar on the left is occupied by the .exe file, I was able to eliminate this using this amazing trick .

So here is my question: how can I determine which dlls are occupying my address space? I tried eMScript, which gives a list with all the DLLs and their addresses, but not the ones to the right of the red bar (shared DLLs). And are there any general recommendations or tips on how to reduce this amount of lost address space? Someone recommended using the "reduced graphics driver", but I'm still not sure if this will be the solution to the correct problem.

The new device is the Motorola MC65, if that matters.

Answer 1

To improve the memory available for .NET CF applications, you can implement the trick described in the MemMaker article for the .NET Compact Framework : moving all managed code from an EXE to a DLL . This can help you free up memory in a 32 megabyte slot.

Other related articles: Killing a Monster Virtual Memory :

• Part 1
• Part 2

Answer 2

great question and info. See My notes.

"... How to determine which DLLs are occupying my address space? I tried eMScript, which gives a list with all the DLLs and their addresses, but not the ones to the right of the red panel (common DLLs)."

Try to find a copy of devhealth. It is an MS tool for displaying all DLLs, as well as addresses and links. See also http://www.hjgode.de/wp/2009/05/27/managed-application-suddenly-fails-to-invoke-dlls/

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

Some of these DLLs are loaded by drivers and background processes. You can “eliminate” some of them by disabling the launch of an application. But I'm afraid most of them are needed by the device / OS. In general, the memory situation on the WM653 should be better than on the WM61. MS has added some additional "memory keepers." But the new OS is also equipped with new features and services, so the "memory improves" less than is possible. If you cannot remove drivers / applications, you must split one application into several processes. For example, if you have a camera photography feature, then divide it into a separate application and get your own 32 MB process slot.