XXX.exe is not a valid Pocket PC Application: Troubleshooting guidelines

XXX.exe is not a valid Pocket PC Application: Troubleshooting guidelines

It is not uncommon for a developer to see his/her program cannot run in the emulator or physical device, after struggling with code development, compilation error and build issues. Most typical error is like "XXX.exe is not a valid Pocket PC application", like the following screen cut. Hereby I am trying to write simple guidelines for troubleshooting such issue.

1. Check the Platform

The executable might be built for a platform that does not match the target device. For example, an executable built for x86 emulator cannot run in any physical device, which supports ARM instruction sets.

In WM5.0, Microsoft introduces a build target called "THUMB", which is a subset of ARM instruction sets. An executable built for "THUMB" can only run in WM5.0 device or emulator. You'll get the above error message if running such executable in Pocket PC 2003 or Smartphone 2003 device.

The way to check the platform is to use "dumpbin /header ", and take a look at the line exposing the "machine" information.

The way to fix platform issue is to change project settings in your IDE (EVC4 or Visual Studio 2005). Both IDEs allow you to manually modify the command line option /MACHINE.

2. Check the SubSystem

An executable built for a lower subsystem (for example, 4.20) can run in a WM5.0 device, but not vice versa. If you try to start a program built for 5.0, you will get the warning "XXX is not a valid Pocket PC application".

The way to check the subsystem is to use "dumpbin /header ", and take a look at the line exposing the "subsystem" information.

The way to fix subsystem issue is to change project settings in your IDE (EVC4 or Visual Studio 2005). Both IDEs allow you to manually modify the command line option /SUBSYSTEM.

3. DLL HELL

The previous two issues are easy to identify and fix, but the third one is very concealing and hard to troubleshoot. In general, if a program needs DLLs (who does not?), the DLL must either be present in the system, or already loaded into memory. If a required DLL is not available, the warning is clear and to the point: "Cannot find 'XXX.exe' (or one of its components). Make sure the path and file name are correct and all the required libraries are available."

However, if the DLL is available or already loaded into memory, but the DLL does not export the required functions, CE OS could not verify that linker time dependencies are met. It shows a super-misleading warning "XXX.exe is not a valid Pocket PC application".

It is hard to find which DLL causes the issue, and even harder to solve the issue. On the desktop, you can isolate yourself to certain extent by ensuring that the DLL you built and tested is the one that is loaded by the OS; one way putting the DLL in the same directory as your application. On Windows CE, to save memory, only a single copy of DLL is loaded into physical memory, and multiple processes share the single copy if all requiring such DLL.

To confirm whether the DLL HELL causes the dreaded message, you can try to find what other processes are using the same DLL, then terminate those processes and start your first. If your program works, then definitely your issue is caused by the DLL loaded by other processes. MFC is a good suspect, since there is so many versions of MFC DLLs (although Microsoft has taken extra mile to name the MFC DLLs with version number, debug/retail, ...)

Wrap Up

Machine or SubSystem mismatch is easy to detect and fix. Please read "Trap of Copying Project Settings in Visual Studio 2005 (/Machine: ARM vs. Thumb, /subsystem: windowsce, 4.02 vs 5.01)" for more details.

Issue caused by DLL-mismatch is much harder to detect. If you run into the issue, and you are use MFC, there is a high possibility that multiple versions of MFC DLLs are the culprit.

====>SiteMap of this Blog<===