Xbox UWP – Unable to Activate Windows Store App – Error 0x8004090a

Building and deploying UWP apps on Xbox is frustrating – every time I come back to it I get caught out by things that should just work. The one that always seems to get me is that you have to be signed in on the Xbox. This used to not be a problem because Visual … Continue reading “Xbox UWP – Unable to Activate Windows Store App – Error 0x8004090a”

Unhelpful ‘Unable to activate Windows Store app’ Error

Building and deploying UWP apps on Xbox is frustrating – every time I come back to it I get caught out by things that should just work. The one that always seems to get me is that you have to be signed in on the Xbox. This used to not be a problem because Visual Studio used to recognise this issue and provide you a nice reminder – I think it was in the Output window but can’t be sure for certain.

I just attempted to debug an app on the Xbox from the latest version of Visual Studio (both preview and stable) and got the following completely unhelpful error message:

Unable to activate Windows Store app 'XXX.YYYYYYYY_ZZZZZZZZApp'. The activation request failed with error 'Operation not supported. Unknown error: 0x8004090a'.

After rebuilding, cleaning the solution, restarting the Xbox and a variety of other things, I remembered to check that a user was signed in on the Xbox. Sure enough it wasn’t and sure enough, signing in, fixed the activation error.

If you come across this error, make sure you’re signed into an account on the Xbox!!!

Decompilers for .NET and Windows (UWP) Apps

I think I’ve been living under a rock as I’ve only just come across dnSpy, a decompiler for .net! I’ve been building apps and services with .NET for a long time, so a Twitter thread talking about decompilers amused me. David Kean’s comment pretty accurately reflects my sentiment regarding Reflector. You can pry ildasm from … Continue reading “Decompilers for .NET and Windows (UWP) Apps”

I think I’ve been living under a rock as I’ve only just come across dnSpy, a decompiler for .net!

I’ve been building apps and services with .NET for a long time, so a Twitter thread talking about decompilers amused me. David Kean’s comment pretty accurately reflects my sentiment regarding Reflector.

Reflector was such a simple tool and it just worked. That was until Red Gate took over and I can’t even remember what happened to it. Does it still exist?

The thread started with Jared commenting that developers should be using ilSpy instead of hacking with ildasm. I’ve rocked ilSpy in my toolkit for a while now and it’s always served me well. In fact I go so far as to set it as the default file handler for .dll files. After all, what other program are you going to want to launch when you double-click on a .dll file.

dnSpy: A Decompiler for .NET

What really knocked my socks off was that someone mentioned dnSpy which I’d never heard of. Thinking it was something similar to ilspy I didn’t think much of it but figured I would download it and take a look.

Next thing I knew it was like I had opened an entire development environment. The layout was familiar, all the way down to the Debug menu that allows me to attach to process.

What? come again? Attach to Process? Yes, that’s right you can attach to a running process, set breakpoints and intercept exceptions (and I’m sure a whole bunch more things. Ironically whilst I was attempting to modify an image of dnspy running, Paint.NET crashed on me. Whilst Paint.NET was hung, I was able to attach to the process using dnspy and see that it was stuck waiting for a print dialog to return.

dnSpy: a Decompiler for .NET

If you’re using ilspy, you should check out dnspy

For anyone still using ildasm, you should check out ilspy and dnspy

Developers not using a decompiler, what have you been doing? Get yourself a decompiler for .NET, and use either ilspy or dnspy.

Nick Randolph @thenickrandolph
If you need help debugging your application, contact Built to Roam

Fiddler Debugging Http/Https Traffic for Xamarin iOS, Android and Windows (UWP) Applications

Debugging Http/Https Traffic using Fiddler for Xamarin iOS, Android and Windows (UWP) Applications

One of the most frustrating things as a frontend developer is when you are receiving incorrect data. You don’t know whether the problem lies with your application, or the backend services. The easiest way to validate this is to pretend to be a hacker. You can stage a man-in-the-middle attack on your own application. Debugging using tools like Fiddler or Charles can be used to inspect the traffic from your application. Unfortunately, the same effort that goes into protecting apps from such attacks, also means that it is harder for developers to setup Fiddler debugging.

In this post I’ll walk through setting up Fiddler debugging for a Xamarin.Forms application. The same basic approach will work for a native or Xamarin iOS/Android application as well. For this post I’ve created an application using the Blank Xamarin.Forms template that comes with Visual Studio 2019. I’ve selected to target all three platforms.

In the OnAppearing method in the MainPage of the Xamarin.Forms application, I’ve added some basic code to retrieve a string for a Https endpoint. We’ll use a Https endpoint on the assumption that if we can intercept Https then we can also intercept Http traffic.

protected override async void OnAppearing()
     var client = new HttpClient();
     var users = await client.GetStringAsync("");

Setting Up Fiddler Debugging

Before we get started with the individual platforms, it’s worth checking your configuration for Fiddler:

  • You need to make sure you have setup Https traffic decryption. I’m not going to repeat the documentation, so check out how to Configure Fiddler to Decrypt HTTPS Traffic.
  • You’ll also need to setup Fiddler debugging for remote traffic. This can be done by opening the Options window. Under the Connections tab, make sure the “Allow remote computers to connect” checkbox is checked. If you’re running Skype, or some other communication tools, it may have jumped onto the default port configured in Fiddler. In this case you can adjust the “Fiddler listens on port”.
Fiddler Debugging Options Window
Enabling remote connection in Fiddler

Windows (UWP)

I’ll start with Windows, because it’s relatively straight forward to get setup. With Fiddler running, you can run the UWP project from within Visual Studio and Fiddler debugging will work. Fiddler will capture the Https traffic without any further configuration or setup.

Fiddler Debugging
Capturing network traffic in Fiddler

In some cases, you need to make sure your application is added to the exemption list, so that traffic can be routed to the local machine. For more information see the blog post Revisiting Fiddler and Win8+ Immersive applications. To check this, click the WinConfig button in the top left corner of the Fiddler interface.

Click WinConfig to adjust the exemption list for Windows 10 apps

Locate your application and confirm that there is a check in the box next to your application. If it’s not checked, check the box, and then click Save Changes

Exemption Utility
Locate your UWP application and check the box to add your application to exemption list

One other issue I’ve seen but can’t reproduce reliably, is that sometimes when you run your application from Visual Studio it unchecks the box in the WinConfig in Fiddler. If for some reason you no longer see traffic in Fiddler for your application, go back and double check the exemption list in Fiddler.

Diagnosing Issues with Fiddler on Windows

When configuring Https traffic decryption, you’ll be prompted to install and trust the Fiddler root certificate. If you don’t accept all the prompts, Fiddler debugging for Windows applications will not work. Windows traffic debugging works without any further configuration because the Fiddler root certificate is trusted on the machine running Fiddler.

If you’re attempting to run the Windows application on a different machine than the one running Fiddler, you’ll need to install and trust the Fiddler root certificate. This is in addition to setting the remote machine as a proxy, which is a topic for another post. Navigate to http://[ipaddress]:[port] where [ipaddress] is the ip address of the machine running Fiddler and the [port] is the port number that Fiddler is listening on. Do NOT use https as this site is http only. You should see a screen similar to the following image – if you don’t, make sure you check that Fiddler is running!!

Fiddler Debugging Echo Service
Click on the FiddlerRoot certificate to install the root certificate

Click on the FiddlerRoot Certificate and install as a Trusted Certificate Authority on the Local Machine. This should allow your Windows application to trust Fiddler.

iOS Fiddler Debugging

Next up is iOS and in this case we’re going to use the iOS simulator. The same process should work with any iOS device that’s on the same local network as the machine running Fiddler. There are two steps to setup iOS for traffic debugging:

  1. Trust the Fiddler root certificate, and
  2. Set the http proxy to use the machine running Fiddler.

To setup the simulator, first launch the iOS application from Visual Studio. If you’re on Windows, this will launch the remote viewer for the simulator. Once the simulator is running, stop debugging and we’ll setup the simulator for traffic debugging.

Trusting the Fiddler Certificate

Navigate to http:[ipaddress]:[port] (eg to load the Fiddler echo page. Then click on the Fiddler Certificate link. Follow the prompts to download and install the certificate.

Fiddler Echo Service iPhone Download Certificate iPhone Download Profile iPhone

In addition to downloading the certificate you also need to install it. Go to Settings / General / Profile and click through on the FiddlerRoot profile in order to Install it.

image image image image image image image

The Fiddler root certificate needs to be trusted as a root certificate. Go to Settings / About / Certificate Trust Settings and toggle the switch next to the FiddlerRoot certificate. Fiddler generates a certificate for each site you go to that is derived from the root certificate, so the root certificate needs to be installed as a trusted certificate.

image image image image

The only difference between a real iOS device and the simulator is that on a real iOS device you can set a network proxy. There are online tutorials, such as this one, for instructions on setting a proxy. Unfortunately, setting up a proxy this isn’t configurable on the simulator. If you want to use a proxy in the simulator, you can set the proxy on the mac running the simulator but this would affect all traffic on the mac. Alternatively, when running on the simulator, we can adjust the HttpClient to use a WebProxy using the following code:

var handler = new HttpClientHandler();
handler.Proxy = new WebProxy("", 8888);
var client = new HttpClient(handler);

Running the iOS application should show network traffic in Fiddler debugging window. You should still see the returned data printed out in the Output window (ie from the Debug.WriteLine statement).

Android Fiddler Debugging

For Android I’m going to use the Android Simulator. Real devices should behave similarly, assuming they’re connected to the same local network as the machine running Fiddler.

Unlike iOS, that will use any proxy configured for the device, for Android you need to explicitly opt in to use a proxy in your code. You’ll need to use code similar to the following on both emulator and real devices:

var handler = new HttpClientHandler();
handler.Proxy = new WebProxy("", 8888);
var client = new HttpClient(handler);

What’s a little scary about this code is that it “just works”. You might be thinking that this is a good thing. However, it does raise the question of how much of the system security model does the Microsoft built HttpClientHandler respect. What I would have expected is an SSL fail exception because the Fiddler root certificate isn’t trusted by the emulator. Furthermore, the application is not configured to use any user certificates.

The other thing to point out here is that you should not be using the HttpClientHandler. I’ve discussed this in my previous post on working with the HttpClient. Let’s change our code by moving it into the OnCreate method of the Android head project. We’ll also change over to using the AndroidClientHandler.

protected override async void OnCreate(Bundle savedInstanceState)
     var handler = new AndroidClientHandler();
     handler.Proxy = new WebProxy("", 8888);
     var client = new HttpClient(handler);
     var users = await client.GetStringAsync("");

When we run the application we see the very familiar SSL handshake exception being raised, which is what we should expect. To get things to work, we now need to install the Fiddler certificate and configure the application to use user certificates.

Install the Fiddler Root Certificate

To install the Fiddler root certificate, navigate to http:[ipaddress]:[port] (eg to load the Fiddler echo page. Click on the Fiddler Certificate link in order to download the certificate. Follow the prompts to download and install the certificate

image image image image image  image

After installing the certificate go to Setting / Security and Location / Encryption & credentials / User credentials to inspect the certificate

image  image

With the certificate installed into the user store, you need to configure the Android project to allow the use of certificates from the user store. In my post Working with Self Signed Certificates (Certificate Pinning) in Android Applications with Xamarin.Forms, I covered this in detail. The quick summary is that you need to create a network_security_config.xml file which sets the trust-anchors property (set using the debug-overrides element) to include certificates from the user store. You then need to reference this xml file from the networkSecurityConfig attribute on the application element in the AndroidManifest.xml file.

After installing the certificate and adding the network security configuration to the Android application you should now see network requests from the application appear within Fiddler debugging window.

Debugging ASP.NET Core with Visual Studio and Docker Desktop

Debugging ASP.NET Core with Visual Studio and Docker Desktop

With Visual Studio 2019 hot off the press I’ve been experimenting with a few of the new project templates and the improvements that have been made in Visual Studio. In this post I’m going to cover how to solve a particularly annoying problem I encountered when attempting to run and debug an ASP.NET Core 3 application from within Visual Studio, hosted within a Docker image. I’ll walk through the whole process of creating the new project and the issue I ran into when first attempting to debug the application.

When you launch Visual Studio 2019, or go to create a new project, you’ll see the Create a new project dialog. We’re going to select the ASP.NET Core Web Application template.


Next we need to provide the standard project information such as name and location.


The next stage is to provide more information about how the template should be configured. Here we’re selecting the API template from the left of the screen, and checking both the https and the Enable Docker Support.

Note: At this point if you haven’t already downloaded and installed Docker Desktop, do it now. It’s a half Gb or so download, so not small, and may take a while based on your network bandwidth.


After creating the template, you’ll see that there are a number of options available to us in order to run the application. We’re going to proceed with the Docker option.


If you haven’t already, make sure you have launched Docker Desktop, otherwise you’ll see the following warning in Visual Studio when you attempt to run the application.


Unless you’ve previously setup Docker Desktop you’ll most likely see the following error. Essentially you need to award Docker Desktop access to a drive in order to create images etc.


Right-click the Docker icon in the tray and select Settings


Under Shared Drives tab, check the local drives you want to make available to Docker Desktop.


When you click Apply you’ll be prompt to authenticate. It will detect the credentials of the current user, which for me is an Azure Active Directory user.


Important: Unfortunately after providing my password and clicking OK, Docker Desktop decides that it will uncheck the drive that I had selected. This seems to be a common issue, raised by a couple of different people online. Anyhow, the following steps demonstrate how to setup a different account and using it to allow Docker Desktop to access the drive. Whilst a bit hacky, this does seem to be the only work around for this issue.

To setup a new account launch Settings, click Other users and then click the + button under Other users.


When prompted to enter email or phone number, instead click the “I don’t have this persons’ sign-in information” option.


Next, click the “Add a user without a Microsoft account” option


When prompted, enter username, password and some security questions. Next you need to change this user to be an administrator, so expand out the account under Other users and click Change account type.


Change Account type to Administrator


Return now to Docker Desktop and enter the new account as part of setting up the shared drive. You shouldn’t see any further issues within the Docker Desktop application.


Attempting to run the application from within Visual Studio again reveals an error, this time complaining it doesn’t have authority to crLeate or adjust folders (including creating files). 


Locate the folder indicated in the error message, right-click on the folder and select Properties. From the Security tab, click Edit.


Add the local account you just created and make sure it’s assigned all permissions.


You may need to repeat this process for 2 or 3 folders that Docker Desktop requires access to, and in some case assigning permissions can take a minute or two. Once done, your application will be launched from within a Docker image, with the Visual Studio debugger attached.

Source Code Debugging with BuildIt Libraries

Source Code Debugging with BuildIt Libraries

I was working on the BuildIt libraries yesterday and got slightly distracted – I was looking for how to make a small change to the way the Nuget packages are generated and ended up investing time in getting symbol source server support added. At first I thought “this is going to be easy and so awesome” but this quickly turned into frustration as it just didn’t seem to work. Turns out that whilst I was able to successfully generate the nuget symbol package locally, what I’d forgotten is that because we separate our build and release process (done via Visual Studio Team Services), I needed to make sure all my source code files are added to the build artefacts. The nuget packages are generated as part of our release process, which includes generating the symbol package which needed to include the source code files.

The upshot is that I’ve got source code debugging added to both BuildIt.General and BuildIt.States, with other packages to get it as we roll out stable builds in the coming weeks.

To get source code debugging to work, the first step is to configure Visual Studio to use the symbolsource server when attempting to step through source code. I followed the instructions at, which I’ve repeated here with the exact setup I used:

In Visual Studio:

  • Go to Tools -> Options -> Debugger -> General.
    • Uncheck “Enable Just My Code (Managed only)”.
    • Uncheck “Enable .NET Framework source stepping”.
    • Check “Enable source server support”.
    • Uncheck “Require source files to exactly match the original version”



With this all setup, you’ll find that the next time you run your application it will be incredibly slow to start debugging as it has to go through and look up the symbols for each library you have references. However, when you do finally get your application up and running you’ll be able to step through and see more information about what’s going wrong with third party libraries that have symbol and source code support.

For the BuildIt libraries (General and States) the only additional step is to update to the latest stable release ( at time of writing). Run the application, and you can now step through on calls made to functions contained within these libraries. You’ll also be able to intercept any exceptions that are raised within the libraries.


Happy Debugging!