共用方式為

Twisted Pixels #3 – Memory Mysteries

  • 發行項

Previous post: Twisted Pixels #2: Doing Graphics! 

What’s going on?

To recap – I have a program that works in the emulator, but does not run on real hardware.  The question is why.

After reading the following memory model posts:

Slaying the Virtual Memory Monster (https://blogs.msdn.com/hegenderfer/archive/2007/08/31/slaying-the-virtual-memory-monster.aspx)

Slaying the Virtual Memory Monster - Part II (https://blogs.msdn.com/hegenderfer/archive/2007/10/01/slaying-the-virtual-memory-monster-part-ii.aspx)

Visualizing the Windows Mobile Virtual Memory Monster (https://www.codeproject.com/KB/mobile/VirtualMemory.aspx)

I strongly suspect that the problem I reported in my last post is memory related. The Donuts2 sample code tests to see if the proper interfaces are implemented in the device drivers, and everything seems ok there. The failure comes during the allocation of memory for a DirectDraw surface, which makes sense for a memory problem.  One other thing – after I posted the last article, I found a device that does run the application, and it has fewer applications pre-installed, and no UI shell.

Windows Mobile 6.1 inherits the memory architecture of Windows CE 5.0, and this model was originally designed when a small footprint was very important. Because of this, Windows Mobile has only 32 MB of virtual memory space for your application to occupy. It does not matter how much memory is built into your device, you can only use that memory in 32 bit slots. There are additional issues that further reduce the amount of available memory, and these are well described in the posts mentioned above, so I will not go into detail here.

Note: This memory limitation has been removed from Windows Embedded 6.0, and we can hope that this change will find its way into a future version of Windows Mobile.

You can’t debug what you can’t test, and there are two tools that let us examine virtual memory conditions on Windows Mobile:

  • DumpMem.exe, which can be downloaded at: https://support.microsoft.com/kb/326164/ . This is an old tool that allows you to create a detailed text dump of the contents of all virtual memory on your device. Part II of Slaying the Virtual Memory Monster gives great detail on how to use this tool.
  • VirtualMemory.exe, which is published on The Code Project in the project “Visualizing the Windows Mobile Virtual Memory Monster“. The link to this project is given above. This is a visual tool that is much easier to use, although it may lack the detail that you need to investigate particularly thorny problems.

toolbox6  I do like the memory visualization tool VirtualMemory.exe included in the page Visualizing the Windows Mobile Virtual Memory Monster (Link above), and have added it to my debugging toolbox, although I can’t use it today. Another invaluable tool allows the creation of screen shots on the device. Although there are several free utilities available, the one I found to work the best was SPB’s “SPB Screenshot” utility, which can be downloaded from the publisher at:

https://www.spbclub.com/forum/viewtopic.php?t=12483

That’s another one for the toolbox.

Because Donuts2.exe runs full screen, and captures all input, I was unable to run either of these memory profiling applications to test my theory. At this point, I could have instrumented the sample to log memory conditions to a file (or perhaps to execute DumpMem), but that is time consuming, and I don’t really care enough about this one example to try. If this was a production application, it would be well worth while to study the information on memory model, and test till there were no questions left. I do have some simple questions that I would like to answer, and I’ll try to do that in a later post.

Although I’ve failed to slay the monster, I think I understand it a bit better than I did before. It seems strange that a sample in the current SDK would fail like this – Perhaps some other phones have fewer apps installed than my stock Diamond. I was able to borrow a few other devices and started testing performance on other devices.

No luck with my old HTC Hermes, and no luck on a Samsung I780. No luck with a couple of other older phones. I was about to give up when a friend dropped by my office to show off a new ASUS P835 running Windows Mobile 6.1. Just for fun we tried it – and it worked. SPBScreenshot does not seem to work with DirectX apps, so you will have to take my word for it, but performance was good, and the app conformed to the large high resolution screen, and the seemed responsive, with a reasonable frame rate.

Out of curiosity I ran VirtualMemory on some of the phones and on the emulator just to get an idea of what can be expected and to look at variance between different phones. DLL space goes from the top of the screen to the bottom.  Program space goes from the bottom to the top.  As I understand it, the limiting factor is the lowest DLL loaded into memory.

Emulator memory map

Figure 1. Emulator memory map (Windows Mobile 6.1)

Diamond memory map

Figure 2. HTC Diamond memory map (Windows Mobile 6.1)

It is clear that the HTC has more DLL memory pre-allocated, which is likely interfering with my application. That’s the price that a user has to pay to have an awesome interface like TouchFLO.

So – the lesson learned today is that available memory varies from phone to phone, and there can be issues that show up on some phones and not on others. It is always good coding practice to check for failure every time you allocate memory, and that becomes particularly important here. One of the challenges of writing games for the mobile platform is dealing with resource issues, and this will remain an issue for the developer of Windows Mobile 6 software.

Next up – Getting Input.

Comments

  • Anonymous
    April 19, 2009
    Wow, so no fix, eh? There are two other thoughts about the cause of the problem.  The first is that the DD driver has an implementation flaw.  This is likely as early last year there was a ruckus and start to a class action lawsuit against HTC for not implementing video drivers.  As I don't believe they intended to slight their customers, I conjecture that there may be driver problems further up the parts chain. The second curiosity is that I found during testing a lot of memory conjestion with Gwes.  Does it play any role in servicing DD create surface calls? If we were out of VM space, shouldn't we be unable to create other surfaces for bitmaps, etc? But we aren't. We simply can't run a call to create a complex surface that ought not exist in the lower 32 anyway, but rather in video memory. Either way, the message is clearly, CE 6 now.

  • Anonymous
    April 20, 2009
    Hi nsohl, I blogged a little about this on http://myitforum.com/cs2/blogs/mnielsen/archive/2009/03/12/windows-mobile-troubleshooting-how-to-log-like-a-developer.aspx. I found out on Doug Boling's blog, http://bolingconsulting.com/blog/?p=4, that WM 6.1 has specific logic around using new sperated memory slots for DLL's above 64Kb in an attempt to reticify some of these memory issues in the "Device" slot. This could be why you are seeing certain applications work better on WM 6.1 devices.