Wednesday, March 9, 2011

Azure sdk 1.3 "Role instances are taking longer than expected to start." bug still exists in 1.4 and I'll tell you why.

After installing the sdk 1.4 released today, it appears that only half the problem was fixed. Initially the following error could have been thrown due to many things, some of which include the following:

On Start Debugging the following errors always occurs:
The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.
Role instances are taking longer than expected to start. Do you want to continue waiting.

1)Exit Both Azure Emulators, clean solution, and redeploy
2)If your project is under source control and your web.config is readonly, make it writable.
Add this to your Post-build event command line in your project properties.
attrib –r $web.config    
…Case sensitive

3)Enable enableNativeCodeExecution in the ServiceDefinition.csdef
4)Made sure only one web role in solution.
5)Made sure only 1 instance count is set.
6)Double checked Copy Local on assemblies
7)Ensure WCF Activation is enabled
8)Run visual studio in administrative mode
9)After running, open iis, and make sure directory browsing is enabled
   Apply network service permissions to root folder which allows azure to dynamically enable directory browsing in iis on vs dev fabric start.
10).net full trust in iis
11)Checked cloud project  .net framework version
12)make sure your cloud project is the start up project
13)make sure your website properties has a start up page set
14) waiishost.exe 60second time out

All of which are easily configurable in order to be resolved, except for #14.

With the new full iis functionality, there is a change in architecture in the way we host the webrole dll.  When we run in the local development fabric,  waiishost.exe talks to the iisconfigurator process through a WCF named piped.  The iisconfigurator process gets the webrole running within iis.  When looking at his named pipe, it has a timeout of 60 seconds. 

The issue occurs because, only if running under the development fabric, then the ACLs are redone on the local resources to make sure IUSR has permissions.  This is called from waiishost and ran in iisconfigurator.  Unfortunately, with the amount of files in a given project, this may take longer than the timeout of 60 seconds and this is what leads to the communication exception.

Unfortunately, this 60 seconds timeout is hardcoded so it can only be resolved one way at the moment…
#14 Solution)
Delete the <Sites> section from ServiceDefinition.csdef and the emulator reverts to using the Hostable Web Core (HWC) rather than Full IIS, and the timeout is avoided.

With the new sdk everything is resolved/or configurable again except for #14. Although, a new error shows which helps provide validation that this is in fact the problem.


This request operation sent to net.pipe://localhost/iisconfigurator did not receive a reply within the configured timeout (00:01:00).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.

Referencing Bill's link in the comment's below, the following may be a feasible workaround. I have not yet tried it, but please feel free to try it out and let me know.

If you must need Full IIS Role and cannot delete the <Sites> sesiont, then you can use the following workaround:
#14 Solution)
a) Please copy all the files (or most of the files) in your virtual directories folder into ZIP files.
b) When the Role starts expand the ZIP file in OnStart() function
c)  IISConfigurator.exe runs before role start so having thousands of files in ZIP will not cause the total time to exceed 60 seconds, and there will be not exception
Hope this helps!


  1. John - FYI, see also this other post on IIS Configurator timeout:

    -Bill (@codingoutloud)

  2. Thanks Bill, looks like that might be a feasible workaround. I will add it to my post for reference.

  3. I'm on Azure SDK 1.5 and was still getting this error. This post fixed it for me:,guid,FC531B14-54C5-4996-9EDE-8C0DB734B0EC.aspx#d85dce93-3245-4e68-9ddf-5c4825775bf5

  4. Hi

    Thanks for your post but none of these helped me.

    However this page DID!,guid,FC531B14-54C5-4996-9EDE-8C0DB734B0EC.aspx#d85dce93-3245-4e68-9ddf-5c4825775bf5

    I stopped the Net.TCP.Portsharing service and all working.