Why can't Visual Studio 2013 see the Remote Debugger running on my Surface?

Question

I am trying to install and run my Windows Store app on a real Surface RT device. I have installed the Remote Debugger for ARM and its running, with no authentication on 4018.

Visual Studio fails to see the device, fails to connect and deploy.

In Windows on the desktop, I cannot ping and my port-query tool says 4018 is down, the host is unreachable.

What can I do? Why didn't they just use USB like Windows Phone development?

Answer 1

Microsoft don't tell you this, but you need to configure some firewall rules for the device to become visible on the network. Of course, you won't find anything by searching for "firewall" from the Start screen, but it can be found as a Snap-in for MMC.

You could turn the firewall off for the Private Profile, i.e. your local, private home network, since your home router already has a firewall and the one in Windows is just there to annoy people; cause family members to call and interrupt your dinner while they struggle to get things working on their budget new Windows 8 laptops (with no touch screen), or you could set the right rules manually.

However there's an easier way, turn on the oh-so-discoverable - especially on a tablet that's not even supposed to even have a desktop - "Network discovery and file sharing" by opening Windows (file) Explorer and clicking on the Network node on the left. A bar will pop up to remind you that Windows is getting in the way and that you can click it to make stuff work again; this configures the firewall for you.

Note that turning on "Network discovery..." via the option under Control Panel > Network Sharing Blah > Instantly-forgettable Name doesn't work. No one knows why.

By now you should be able to ping you device and the port is open, just in time for your battery to have gone flat.

Important Edit

Today, its not working again and pop-up doesn't appear again so I cannot try the same trick. My port query tool says the port is not open (it was the other day).

So I tried this, but its not working for me.

# Elevated Command Prompt #
netsh advfirewall firewall add rule name="RemoteDebugger" dir=in action=allow protocol=TCP port=4018

That says 'Ok.' but the port isn't open.

So I went into MMC and added the Firewall snap-in and its enabled itself again for the Private profile.

Then I noticed that it doesn't turn off. If you flip it to Off and hit Apply, it does nothing!!

There are now two inbound rules for the Remote Debugger, the one I setup and another for the executable. Still, doesn't work.

This thread:

http://answers.microsoft.com/en-us/windows/forum/windows_rt-networking/possible-windows-firewall-bug-on-surface-rt-blocks/caa8b40c-dacc-4d19-a751-7a04f8ef00e4

There's an answer stating:

1. Open Control Panel -> Administrative Tools -> Windows Firewall with Advanced Security.
2. Click "Windows Firewall Properties" in the main frame

3. In each of the three tabs of Domain, Private and Public Profile:

   1) Note that: If you change "Firewall state", or change "Inbound connections" to "Allow" (inbound connections that do not match a rule are allowed), it is not going to work. The change is immediately lost after you click "OK" or "Apply" to close the dialog box.

   2) What you need to do is: click Protected network connections: "Customize", it will show another dialog box, in which you can deselect some network connections. In this case, you can uncheck "Wireless" and leave "Bluetooth" on.

4. Once you finish step 3, Action Center will pop up an alert, saying Windows Firewall is off or not using recommended settings. You can ignore this alert, or turn it off in "Change Action Center settings".

Though someone on that thread confirm it had worked, it hasn't for me.

Luke