Troubleshooting Windows Phone App Problems that occur after Submitting

A Windows Phone 7 or 8 application may run flawlessly during development and testing, but after submitting it for certification testing, the application may crash or perform unexpectedly. Along these same lines, your application may not perform as expected after publication. This article explains the most common reasons for this, along with remedies.

This article may also be helpful for debugging Windows Phone applications that you deployed to your own private Company app distribution.

As part of the Certification Testing process, applications are tested as if they were installed from the Windows Phone store. In the cases outlined below, the application will fail certification with a crashing error that cannot be reproduced by the developer using the Windows Phone SDK alone.

In an effort to reproduce these problems, you can test your application using the beta release service offered by the Dev Center. This enables you to submit a private Beta application, which is not distributed to the public. This version of your application can include logging to the UI etc., in order to make it easier to analyze; this is particularly helpful if the failure is occurring after the main page has successfully launched.

You can download the call stacks for the crash, by reviewing your Dev Center Dashboard crash dump logs although the log results amay be of limited value. Follow the procedure below to enable crash reporting:

1. For the phone being tested, go to Settings, Feedback and set it to ON. 
2. Make sure the phone has Wi-Fi access.
3. Launch the application.
4. Inspect the crash dumps in your Dev Center dashboard.

The following issues are known to cause the app to crash only after the app is installed from the Windows Phone Store and during Certification Testing. When side-loaded, the application runs fine.

1. Calling ScheduledActionService.LaunchForTest in a Windows Store installed app. Make sure all debug APIs such as ScheduledActionService.LaunchForTest are not included in your release build. The app will crash otherwise.
2. Writing to the InstalledLocationfolder in a Windows Store installed app. Do not write to the InstalledLocation folder in your production application release submitted for certification. This will cause an app crash. The folder is readable and writable before it is published, but in the published app, the folder is read-only. You can however read and write to the Local Folder. For more information, refer to Data for Windows Phone.
3. Coding a dependency on a hard coded product id value. Before Marketplace deploys the app, its ingestion process changes the ProductID in the WMAppManifest.xml. Perhaps your app has some dependency on the ProductID that existed beforehand. An example is if your app has a hard copy of the old ProductID in a string constant. Your app may need to explicitly open WMAppManifest.xml and then inspect the ProductID in order to get the correct value.
4. (Windows Phone 7 only) In the Dashboard, inspect the list of Capabilities for your published app, and ensure that Marketplace didn’t remove any. This problem can occur owing to the various ways Marketplace audits the app in order to identify what capabilities are needed. The solution depends on which capability is missing. As a Windows Phone 7 example, for MediaElement to be detected, its name needs to exist in the xaml itself (x:name). Find more information about Capabilities here.
5. Submitting a XAP file for x86 instead of ARM. Ensure that you built your solution targeting the Device not the Emulator. The Emulator compiles to the X86 platform while the device compiles to ARM. In this case, the app won’t be able to be tested.
6. App won’t load on low memory devices (512 MB – Windows Phone 8). See if the failure is specific to a particular phone model or manufacturer. For example, determine if the problem is related to the amount of memory available in the phone.
7. If your application does fail certification, make sure you refer to the “Windows Phone Tested” section of the failure report for a list of devices on which their application was tested so you can attempt to reproduce the failure on the same devices if possible.
8. Developers should pay attention to the failure reason comments in the Certification Testing report to see if the issue was encountered on Windows Phone 7, Windows Phone 8 or both platforms and make sure you are attempting repro on the correct device/OS.

These scenarios are known to cause Dev Center submission and/or run-time errors:

1. Not running the Store Test Kit prior to submitting your app to Dev Center. In Visual Studio, under the PROJECT menu, choose Open Store Test Kit. Execute the automated and manual tests. Make any necessary corrections. More information is available here.
2. Submitting to Dev Center a debug, instead of a release build of your app. Make sure that when you built your solution, you did so in Release mode, i.e. not Debug mode. In Visual Studio, check this using BUILD->Configuration Manager… If you uploaded a Debug build you will get static validation errors during submission, for example if the app includes native code. Also a debug build will generally result in an app that runs slower to the end user, because of extra debug checks and diagnostics.
3. Ensure that the XAP file contains all the DLLs needed. For example if using the Windows Phone Toolkit or other third party libraries, make sure the references to those DLLs indicate CopyLocal=true. Your XAP file can be found in the Bin/Release folder of your project. Inspect its contents by renaming a copy from .XAP to .ZIP. Then double click on the newly named file to inspect its contents. You also can inspect it by using a third party tool such as WinZip.
4. Also while inspecting the XAP, make sure all the DLLs that are present are known, expected DLLs, and those DLLs have been compiled specifically for use with your particular version of Windows Phone app and build environment. You might need to launch a clean build to ensure there are no unnecessary DLLs.