Behind Azure Remote Debugger
As you might already now Windows Azure offers remote debugger for debugging of Cloud Services within Visual Studio.
Good starting point to learn about debugging of cloud services is following article: http://msdn.microsoft.com/en-us/library/windowsazure/ff683670.aspx
However before you attach the debugger there are few things which you have to be aware.
First of all, we have to distinguish between debugging of Azure Web Sites and Windows Azure worker roles. Both are cloud services,
but the way how they work and how they can be debugged is different.
Do not be disappointment with this statement. As developer you will in both cases simply use Attach Debugger option and use debugger as usual.
The only difference which is important to you as a developer is set of ports which have to be enabled. If required ports are not enabled you will get exception like this one:
“Failed to enable remote debuggingException from HRESULT: 0x89710023”
Debugging Azure Web Sites
Debugger for Azure Websites is a part of Websites infrastructure. So, when you deploy Website, debugger is already in place. Under the hub this Debugger uses a TCP channel, which is in WCF world known as NetTcp binding.
On the wire debugger uses a TCP connection on a port 4016 or 4018 (Visual Studio 2012 and 2013 respectively). Additionally on this port is authentication tunneled too. So if you want to “Attach” to Windows azure Website open one of named ports.
There is much more magic behind all this, which is implementation detail. But think about Websites and multiple tenants running on the same machine. In this case debugger will know the process in which your site is executing and route all required information to the right debugger if more developers are connected in the same time to the coincidently same box.
Debugging Azure Worker Roles
Interestingly, in a case of worker role based cloud services debugger works slightly different way. Right now, debugger bits with some additional components will be deployed under the hub with CSPACK. In other words, debugger of Worker Roles is at the moment not a part of Worker Roles infrastructure. But there are no any disadvantages with this concept for you as developer. If this change in the future, you will probably not know this.
For you it is important that under the hub all debugger related components (including remote debugger itself) uses ports 4016 and 4017 for internal communication. That means that your application which is running as Worker Role MUST NOT use these ports. Communication between Visual Studio and Remote Debugger is covered on ports 30400-30424 and 31400-31424 (VS 2012 and VS 2013 respectively).
How test connection?
The best way to test is to attach the debugger. However, there are might be possible some other reasons than TCP port, which prevent debugger to attach.
To be sure that the TCP port is open you can use telnet. Go to Windows azure Management portal and copy the URL of the endpoint of your site or worker role.
Then try to connect to port 4018 (VS2013) or 4016 (VS2012).
If debugger is reachable after few seconds (10-15 sec.) following will appear:
If required ports are not open you will get following error:
| Ports | Purpose | Used by | Required to open on firewall |
| 30400-30424 | TCP Port used for communication between Visual Studio and Remote Debugger | VS 2012 Worker Roles | YES |
| 31400-31424 | TCP Port used for communication between Visual Studio and Remote Debugger | VS 2013 Worker Roles | YES |
| 4016 and 4017 | Ports internally used by remote debugger and related components | Worker Roles | NO Used on the VM where Worker Role process is running |
| 4016 | TCP Port used for communication between Visual Studio and Remote Debugger | VS 2012 Windows azure Web Sites | YES |
| 4018 | TCP Port used for communication between Visual Studio and Remote Debugger | VS 2013 Windows azure Web Sites | YES |