Using Windows Azure PowerShell Sample to Investigate Issues with Cycling Roles

Tweet

After posting Windows Azure Deployment Stuck in Initializing, Busy, Stopping – Why? two weeks ago, I received quite useful feedback from colleagues in our support centers. It is related to the problem with the missing DLLs that may cause your role to be cycling between those states.

 

Retrieving a List of Available DLLs on the Guest VM

If you want to check whether particular DLL is available on the VM your role is running on, you can use the PowerShell sample that comes with the SDK.  In order to do that you need to deploy the sample, and type the following command in the script box:

 

dir d:\ -include <name of file> –recurse

 

If for example you want to check whether System.Data.DLL is available on the VM you should type:

 

dir d:\ –include System.Data.DLL –recurse

 

and somewhere in the results you will see something like this:

 

Directory: Microsoft.PowerShell.Core\FileSystem::D:\Windows\assembly\GAC_64 \System.Data\2.0.0.0__b77a5c561934e089

Mode    LastWriteTime         Length     Name

----    -------------         ------     ----

-a---   4/11/2009 4:12 PM     3008512    System.Data.dll

 

This means that System.Data.DLL is available in D:\Windows\assembly\GAC_64 folder. You can ignore the majority of the output that shows “access denied” because you don’t have access to those folders anyway.

 

OS Version Dependencies

One thing to pay attention here is the OS version dependency. As you already know Windows Azure introduced Operating System Versioning in Windows Azure back in December 2009 (I may post some OS specific clarifications in the future), and there may be differences in the DLLs included in the different OS versions.

Make sure that you deploy the PowerShell sample on a VM that runs the same Windows Azure OS version as your application.

 

Checking References in Visual Studio

Here is one more way you can use to check whether the DLL is available on the VM. If you reference DLLs from .Net Framework 2.0 or 3.5 you can be sure those are available on the VM. You can check this in Visual Studio with expanding the References node under your role and selecting particular reference. In the Properties window find the Path property, and verify whether it is under one of the following folders:

 

C:\Windows\Microsoft.NET\Framework\

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\

 

If the reference does not point to a DLL under one of those two folders you need to set the Copy Local property to true.

 

Special thanks to Kevin W. from Microsoft support center in Las Colinas and William B from Microsoft support center in Charlotte for this information.