1

We implemented a build pipeline for our UWP app on VSTS. We can build the application on any of our developer workstations in release mode with .NET native enabled and the app works as expected.

When we build the same application on a Hosted VS2017 Agent in VSTS, the application also builds successful and the resulting appxbundle file can be installed on a device. However, the application crashes right after showing the splash screen.

I can't see any difference in the way we build the application in VS2017 compared to the way it is build on the Hosted VS2017 Agent in VSTS.

The event log shows the following right after the crash:

Faulting application name: Foo.exe, version: 0.19.1.0, time stamp: 0x5a1d8e4a Faulting module name: Windows.UI.Xaml.dll, version: 10.0.16299.15, time stamp: 0xf6706fe0 Exception code: 0xc000027b Fault offset: 0x00000000006e7269 Faulting process ID: 0x3044 Faulting application start time: 0x01d368691c216952 Faulting application path: C:\Program Files\WindowsApps\Foo_0.19.1.0_x64__fdr8vq4bd9b2a\Foo.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report ID: 2655f631-947c-42e5-b3d4-2d2679a93332 Faulting package full name: Foo_0.19.1.0_x64__fdr8vq4bd9b2a Faulting package-relative application ID: App

The build step in VSTS is configured as following:

/p:AppxBundlePlatforms="$(BuildPlatform)" /p:AppxPackageDir="$(Build.ArtifactStagingDirectory)\AppxPackages\\" /p:AppxBundle=Always /p:UapAppxPackageBuildMode=StoreUpload

If I use the same command line and run it on any developer workstation it works and the resulting appxbundle can be installed and started without any crash.

Any idea what the difference could be or how I can debug the app best?

Sebastian Zolg
  • 1,921
  • 2
  • 14
  • 35
  • This is not just going to happen because of a wonky build machine, you'll get these kind of failures on the user's machine as well. So learning how to debug them is pretty crucial and you haven't made the first dent yet. Google "uwp debugging stowed exception" to get ahead. – Hans Passant Nov 28 '17 at 18:00
  • thanks @HansPassant - I used windbg a minute ago and got Failed to assign to property 'Prism.Windows.Mvvm.ViewModelLocator.AutoWireViewModel'. No Idea how to narrow it further...any idea? – Sebastian Zolg Nov 28 '17 at 18:08
  • Can you reproduce this issue with a new project? You said that "We can build the application on any of our developer workstations in release mode with .NET native enabled and the app works as expected.", do you mean you build the app through private build agent or just build the app through command manually? You can share a sample project on the OneDrive, which can reproduce this issue. – starian chen-MSFT Nov 29 '17 at 05:18
  • @starianchen-MSFT I only have this effect on the hosted build agent in VSTS compared to building the solution through visual studio on all developer machines - no private build agent involved here. That's why I can't reproduce it. Any suggestion what could be the difference between visual studio build and the hosted agent builds? – Sebastian Zolg Nov 29 '17 at 05:27
  • Just the environment is different. You can try to setup a [private build agent](https://learn.microsoft.com/en-us/vsts/build-release/actions/agents/v2-windows) and try again. – starian chen-MSFT Nov 29 '17 at 06:45
  • @starianchen-MSFT Same behaviour on the private build agent. Meanwhile I found the issue - basically the build result is fine but gets corrupted by App Center upload task in VSTS. See my answer post. – Sebastian Zolg Dec 10 '17 at 11:31

1 Answers1

1

The issue is caused by a upload task to App Center (aka Mobile Center) within the build pipeline of VSTS. This tasks seems to "corrupt" the file in a really strange way.

I replaced the task with one using the App Center CLI and the upload works and the app no longer crashes.

I posted another question for the root cause here: Distribute UWP App to App Center (aka Mobile Center) using VSTS Task

Sebastian Zolg
  • 1,921
  • 2
  • 14
  • 35