After upgrading to the Azure SDK 2.8.1 yesterday, I'm unable to debug this application locally without an uncomfortable contortion.
The application is a Microsoft ASP.NET MVC website set up to run using IIS Express. It uses some Azure components, in particular the evil msshrtmi.dll that has caused so many versioning headaches in the past.
The symptoms are these: when starting to debug the application in Visual Studio 2015, the application compiles but immediately causes a system toast message to appear that announces "One or more errors occurred running IIS Express." Clicking there for more information opens this unhelpful dialog box:
The log file contains this single line:
Failed to register URL "http://localhost:64079/" for site "BlogEngine.NET" application "/". Error description: Access is denied. (0x80070005)
The other links point to articles on the MSKB, one of which is out of date and the other of which is probably irrelevant (because I'm running VS2015 as administrator).
I'll get to those in a second, because in reviewing the Windows application and system logs, I found some suspicious events that seem related.
In the Application log, there are multiple error events with IDs 2269 and 2276 that start after I installed the Azure SDK update. Event 2269 is: "The worker process for app pool 'Clr4IntegratedAppPool', PID='11000', failed to initialize the http.sys communication when asked to start processing http requests and therefore will be considered ill by W3SVC and terminated. The data field contains the error number." The error number is 0x80070005 with another code 13780. Event 2271 is just a cascading error, "The worker process failed to initialize correctly and therefore could not be started."
Googling Event 2269 yields quite a few articles but they seem to diverge from my problem very quickly. I'll plow through those in a minute.
The other interesting event is in the System log. Whenever I attempt to debug the app, Event 15005 appears: "Unable to bind to the underlying transport for [::]:64079. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine. The data field contains the error number."
Well, that's a lot more interesting. And it led directly to this article, which led to me looking at what is actually listening for what, which led me to changing the port in my debugger from 64079 to 49156. (I could see that 49156 was free by running netstat -aon.)
Sigh. I have no idea why upgrading to the latest Azure SDK would hose an IIS Express port, but even more than that, I am not entirely sure whether blaming the SDK is itself post hoc reasoning. But like so many things in systems this complex, I have now fixed the symptoms, and will go on with my life. Such a time suck, though.