Skip to main content

Windows 8 application returns “Unable to connect to the remote server” when sending requests to an internal test server

After weeks of testing, we were finally ready to release a first version of our Windows 8 app to our key user. So I created a package and copied all the files on an USB stick to ‘side load’ the application on his machine.  After running the Powershell installation script, installing the developer certificate,  the moment was finally there. The application started and the main hub was shown.

However the moment, the user started to click around and HttpWebRequests were send out to our backend services, the application failed with the following error message:

Unable to connect to the remote server

System.Exception {System.Net.WebException}

An attempt was made to access a socket in a way forbidden by its access permissions

We were clueless why it failed. We tested the application for weeks without any issue. The only difference is that we hosted the backend API somewhere else. Could this cause the issue? We were using a DNS that was mapped differently depending if you connect internally or externally.

The first thing we tried to do, was to add Fiddler into the mix to see what was going on. This made the experience even stranger because suddenly all web calls started to succeed?!            

In a desperate attempt, I opened up the Windows 8 manifest and added the capability for Private Networks:

PrivateNetworksWin8

The Private Networks (Client & Server capability provides inbound and outbound access to home and work networks through the firewall. This capability is typically used for games that communicate across the local area network (LAN), and for apps that share data across a variety of local devices. If your app specifies musicLibrary, picturesLibrary, or videosLibrary, you don't need to use this capability to access the corresponding library in a Home Group. Inbound access to critical ports is always blocked. The capability is written in the AppxManifest.xml file as the following code shows:

Afterwards the application worked fine.

Anyone with more insight who can explain why this solved the issue? I’m guessing this is required because the DNS is resolved to an internal network address…

Remark: To validate if my guess was correct, I removed the capability again and this time connected from outside our company network. I started the application and everything was working as expected.

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more