HoppeRx - the cure for your ailing device

A community site dedicated to the support of device problems found by Hopper

Virtual Memory, Hopper and your device

Virtual Memory, Hopper and your device

Rate This
  • Comments 26

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
  • OFF TOPIC re HOPPER SET UP

    Hi,
    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?
  • Paul - no problem. Please make sure your SystemParametersInfo(SPI_GETPLATFORMTYPE...) is returning "PocketPC", this should outlined very specifically in your "oem requirements" documentation.
  • Many Thanks, all sorted with change to kernel ioctls.
  • Hi,
    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?
  • 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.
  • Hi shende,
       Thanks for answering the question.
    Hope we can see your upcoming blog of the solution soon. I am looking forward it.
  • 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?
  • Hi Shende,

    We already confirm that there is memory leak of device.exe, is there any tool for further investigation ?
  • 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?
  • 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.
  • 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?

    Thanks
  • 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.
  • Hello...

    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?
  • 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.
  • 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.

Page 1 of 2 (26 items) 12
Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post