Workaround for IIS Express Crashing
The Cloud Zone is brought to you in partnership with Iron.io. Discover how Microservices have transformed the way developers are building and deploying applications in the era of modern cloud infrastructure.
I ran into this weird issue when developing a very simple Windows Azure Cloud Service Web Role using Windows Azure SDK 1.8. I started off with a basic ASP.Net MVC 4 Web Role with no changes whatsoever. When I tried to debug it with just one instance running, everything worked great. The moment I increased the number of instances to 2 (or more than 1) and tried to debug it, IIS Express crashed with the following entries in event logs:
Faulting application name: iisexpress.exe, version: 8.0.8418.0, time stamp: 0x4fbae3d6
Faulting module name: ntdll.dll, version: 6.2.9200.16420, time stamp: 0x505ab405
Exception code: 0xc0000008
Fault offset: 0x0000000000004c39
Faulting process id: 0x54bc
Faulting application start time: 0x01cdfeb70c1e060e
Faulting application path: C:\Program Files\IIS Express\iisexpress.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 4a8f54b2-6aaa-11e2-be81-9cb70d025a13
Faulting package full name:
Faulting package-relative application ID:
Fault bucket 79240842, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0
These files may be available here:
Rechecking for solution: 0
Report Id: 4a8f54b2-6aaa-11e2-be81-9cb70d025a13
Report Status: 17
Hashed bucket: b615b24f7933990317ae65713d680dab
This issue does not happen on all machines. I asked a few of my friends to try on their computers and some of them were able to recreate this problem while others couldn’t. My development environment was Windows 8, Visual Studio 2012 and Windows Azure SDK 1.8.
Since I was facing this problem and a few of my friends are also facing the same problem, I thought there may be many more folks who may be facing same problem and hence this blog.
Windows Azure product team helped me find the cause of the problem and gave me a workaround which fixed the problem. I’m also told that this issue will be fixed in the coming versions of SDK but till the time the new SDK comes, the workaround recommended by the team can be used to address this problem.
From what I have been told, this is related to an issue with Windows Azure SDK 1.8 and it happens because IIS Express is trying to bind same IP address to multiple instances. Here’re the entries from applicationHost.config file for 2 instances in which I was trying to run my application which let the product team to that conclusion:
<site name="deployment18(110).WindowsAzureService3.WindowsAzureService3WebRole_IN_0_Web" id="1273337584"> <application path="/" applicationPool="b31dc554-ad4b-4a18-8a62-098b5079f26d" enabledProtocols="http"> <virtualDirectory path="/" physicalPath="D:\Projects\WindowsAzureService3\WindowsAzureService3WebRole\" /> </application> <bindings> <binding protocol="http" bindingInformation="*:82:" /> </bindings> <logFile logExtFileFlags="Date, Time, ClientIP, UserName, SiteName, ComputerName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, BytesSent, BytesRecv, TimeTaken, ServerPort, UserAgent, Cookie, Referer, ProtocolVersion, Host, HttpSubStatus" logFormat="W3C" directory="C:\Users\Gaurav.Mantri\AppData\Local\dftmp\Resources\40fae03f-8519-4c66-a36b-da8e2de73e9d\directory\DiagnosticStore\LogFiles\Web" period="Hourly" /> <traceFailedRequestsLogging enabled="true" directory="C:\Users\Gaurav.Mantri\AppData\Local\dftmp\Resources\40fae03f-8519-4c66-a36b-da8e2de73e9d\directory\DiagnosticStore\FailedReqLogFiles\Web" maxLogFiles="1000" /> </site>
<site name="deployment18(110).WindowsAzureService3.WindowsAzureService3WebRole_IN_1_Web" id="1273337584"> <application path="/" applicationPool="92214b82-0516-4502-8e38-4d94c3cdf949" enabledProtocols="http"> <virtualDirectory path="/" physicalPath="D:\Projects\WindowsAzureService3\WindowsAzureService3WebRole\" /> </application> <bindings> <binding protocol="http" bindingInformation="*:82:" /> </bindings> <logFile logExtFileFlags="Date, Time, ClientIP, UserName, SiteName, ComputerName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, BytesSent, BytesRecv, TimeTaken, ServerPort, UserAgent, Cookie, Referer, ProtocolVersion, Host, HttpSubStatus" logFormat="W3C" directory="C:\Users\Gaurav.Mantri\AppData\Local\dftmp\Resources\3c7c31cb-a2fb-4809-aadb-9238acb2f092\directory\DiagnosticStore\LogFiles\Web" period="Hourly" /> <traceFailedRequestsLogging enabled="true" directory="C:\Users\Gaurav.Mantri\AppData\Local\dftmp\Resources\3c7c31cb-a2fb-4809-aadb-9238acb2f092\directory\DiagnosticStore\FailedReqLogFiles\Web" maxLogFiles="1000" /> </site>
As you can see from above in the “binding” section, both instances were trying to bind to port 82 and hence the error.
There were two workarounds recommended by the Windows Azure SDK team:
Install Visual Studio 2010 SP1
If you’re using Visual Studio 2010, it is recommended that you install SP1 for that. Seemingly that takes care of this problem. Since I don’t have VS 2010 on my machine, I did not try it as it was not applicable to me.
Add an Environment Variable
Other workaround recommended was to add an environment variable called “_CSRUN_DISABLE_WORKAROUNDS” and set the value of this variable to “1”. To set an environment varaible, search for “Control Panel” and then go to “System” –> “Advanced system settings” –> “Advanced” tab –> “Environment Variables…” button –> “New…” button.
I’ve also added a screenshot for your convenience as well.
After you do that you would need to restart IIS Express and Compute/Storage Emulator.
I tried this approach and it worked for me.
Hope this helps!