Virtual Memory, Hopper and your device

The HangRx.exe debugging tool can help you resolve thread priority issues created by Hopper – but does little to empower you to quickly identify issues resulting from Virtual Memory (or the lack thereof). Most Windows Mobile users are already aware that VM is a rare resource and certain programming practices can introduce stability problems as a direct result of running out of VM.


In response, I have created a new logging tool called MemoRx.exe (“Memory Doctor”) that will graphically snapshot VM vitals so issues and problems can be easily and quickly identified visually. This new tool gathers the current state of VM on your device and logs a file to \windows\memoRx.txt (or \release\memoRx.txt if you are connected with KITL) where it can be easily viewed. It should be said that this log is intended to alert the user to any potential problems and does not provide detailed information or solutions to potential VM conflicts. The intent is to allow the user to quickly glance at the report and know if VM is a likely culprit – detailed investigation still requires other memory tools such as devhealth.exe and mi full.


The following sample, abbreviated output from the MemoRx.txt log:


Note how each executable has a slot along the X axis that shows graphically shows VM usage with ASCII type. When a new application is loaded, a new column will be generated and the report will grow in width – up to 32 processes. At the top, the tilde “~” characters represent DLL space that is shared amongst all executables in Slot 0. Below, the dot “.” characters represent VM memory based at 0x0 + VM Base and include stacks, code and heaps. Please note how the dot “.” changes into a pound “#” to flag a conflict between application VM and DLL VM space – this situation can result in an eventual exception and should be investigated.


This tool is being uploaded to the Power Toys section on Jetstream and is appropriate for both Smartphone and PPC platforms. You can run this program either from a storage card or directly from the user store – or you can use the focusApp post below to automate running this tool continually during your Hopper runs to give you a visual clue to VM status on exit.


This is the first of several posts I will focus on Virtual Memory and the common issues our customers have. So keep checking back and thanks for supporting your HoppeRx blog!

Comments (26)

  1. PaulN says:



    I hope this is appropriate…

    I have a PPC 2003 (Release2) device that is in development. I have implemented the LTK early in the development cycle but I am unable to run Hopper.

    Can you let me know where Hopper reads the Product String from?

    When I try to run Hopper I get "Unknown prouct ‘X-Scale’. Product string required. Test will not be run on this platform"

    We know that the processor supports ARMV4T so I guess it is a matter of locating where "X Scale" is in the code?

  2. shende says:

    Paul – no problem. Please make sure your SystemParametersInfo(SPI_GETPLATFORMTYPE…) is returning "PocketPC", this should outlined very specifically in your "oem requirements" documentation.

  3. Paul N says:

    Many Thanks, all sorted with change to kernel ioctls.

  4. Winson Ho says:


    When I got a conflict between application VM and DLL VM space(mark as ‘#"), and I also use DevHealth to dump a detail log. How do I investigate what is going on will the momory usage? And is there any chance to free unnecessary DLL or application?

  5. shende says:

    Yes, DevHealth is the correct way of tracking down these types of issues. I doubt it is likely that you can simply free DLL’s since they should be freed when their refcounts decrement to 0. The answer is to reduce the total number of DLL’s that your applications use by linking code that is not shared as static libs. There are a number of other possible solutions (which I will cover in an upcoming blog) and they all depend on your particular implementation.

  6. Winson Ho says:

    Hi shende,

       Thanks for answering the question.

    Hope we can see your upcoming blog of the solution soon. I am looking forward it.

  7. Winson Ho says:

    Hi Shende,

      I run the MemoRx.exe on my new smartphone device. The memoRx.log only shows an error as "ERROR: ROMChain not found! (is you NK up-to-date?)". What does that mean?

  8. Carol says:

    Hi Shende,

    We already confirm that there is memory leak of device.exe, is there any tool for further investigation ?

  9. Thirupathi Reddy says:

    Hi Shende,

    I have tried to run hangrx.exe on device emulator platform. It works fine. But when wmplayer is active, there is a conflict between the WMPlayer VM and DLL VM space and hence it shows Pounds "#". It gives the following figures for wmplayer:

    Vm Used: 0x45b01000

    Vm Remain: 0xbbe3f000

    Why is it showing VM available to WMPlayer as 0xBBE3F000?

    I have tried to investigate this using "mi full". It does not use so much of VM reported by memorx.exe. What do you think could be problem?

  10. shende says:

    First, understand that the large hexidecimal value reporting VM available is actually a negative number in decimal. This indicates you have ‘crossed over’ and have negative VM in this process space.

    mi full won’t always tell you the full story and you need more advanced debugging tools like devHealth (shipped with Magneto) and nkDebugX (available as a powertoy) to help you understand where this VM is being used.

    It should be noted that just because you ‘crossed over’ your device will fail, it only means your device is at risk.

  11. AlexK says:

    hello shende

    Our vertical Magneto device upon released had already after boot the leak of about 2.3 Mb of VM in device.exe slot.

    We got the solution of this and reached ~10 Mb of free VM by 3 steps:

    1. determining all dlls used by device.exe and placing them in modules (slot1/fised);

    2. moving the heap of device.exe to reside onto 2Gb Kernels memory.

    3. causing all calls from our OAL to VirtualAlloc to submit more than 2 Mb to cause 2Gb Kernels memory usage.

    I would like to ask your opinion about these actions?


  12. shende says:

    Alex, 10mb free should be plenty for a vert. device. From your statements, it would appear you have done an excellent job of easing your pain by utilizing the "upper" VM space. Since this appears to be a vertical device, you know in advance what applications will run and can ‘know for sure’ what the ultimate VM usage will look like.

    My opinion: excellent work.

  13. Byeong says:


    If the crash was happened on the device.exe, is it possible that other processes that use certain dll on crashed region(####)can result in an eventual exception?

  14. shende says:

    Yes, it is "possible" the conflict caused the exception – it is too hard to say given the limited information.

    However, just becuase there is a conflict, does NOT always mean there will be an exception – it depends on if the conflicting process is trying to access shared code within that conflict. Unfortunately device.exe is usually the biggest and also likely to load additional DLL’s.

  15. Geoff Davies says:

    Given that these tools are generally available for the people who are running PB or for use with KITL, are the tools available (or can they be made available) for those users who are developing applications and have already run into the VM problems. In an organisation such as ours, the OS development is done at other sites, and we aleready diagnosed a VM problem where the OS is not loading resources into memory. A tool such as this would make reporting OS issues easier to be diagnosed and fixed.

  16. lowiq says:

     hi, shende…

     I have read all the post here, and have some question…


    "1. determining all dlls used by device.exe and placing them in modules (slot1/fised); "

    Q: How can we do it? I cann’t find any help on google and MSDN…Would you mind giving us a URL?

  17. Jim Row says:

    Is MemoRx source available (possibly as Open Source) to allow for customization and further enhancements ?



  18. Ian says:

    Is Dll low address fixed? or variant?

  19. Jason says:

    Can you post the source or have MIPS/X86 build? thanks in advance

  20. Jim Row says:

    We been writing our own version of Memorx and the results we receive being quite close to MemoRX findings are not the same on several processess.  

    I am sure there are several others in the mobile development community who are doing the same and have the same question as I do…

    Could you provide more details on how the "highest address" of allocated VM is computed for each process?  

    Heap Walking provides quite a bit of details but my upper memory address on several processes does not match with what Memorx reports.   It would suggest an error in our computations, but where?

    Kind regards,


  21. luckytigerwood says:

    Hi shende:

    Could you please help me to know, how to use powertoy – nkDebugx?

    It just a DLL, and i can’t find help document to use it ,thanks!

  22. Miller.Fu says:

    Hello Shende

    I encountered a problem. I hope you can help explain. Thanks in advacne. According to memorx.exe debug message, the windows media player always is overflow when it plays a local file. But the device runs properly. No abnormal things happen. Is this a potential problem? Or it is a bug of Memorx.exe.

  23. Many OEM’s have already noticed that Memory Doctor doesn’t correctly represent VM overlap in pre-release

  24. haibo says:

    There did have some problem ,when use the MemoRx.exe to check VM when use WMPLAYER.EXE in WM6.0.There will always show "#".But the VM is fine when you use devhealth.exe to check the device.

  25. Mark23 says:

    You really know what you are talking about and can explain things really well.

  26. Varun W says:


      Should Hopper be run on apps with a GUI? When I run hopper on my device I get access violations with devhealth.exe which is getting launched by hopper. This app does not have a GUI so I was curious if Hopper can be run on apps with GUI only.

    – Varun

Skip to main content