General Troubleshooting in Windows Azure

If your application runs in the compute emulator but is not behaving as expected after being published to Windows Azure, the problem may be that a role in your application depends on administrative privileges that are present on the your computer, but not in Windows Azure. In the compute emulator, a role runs with administrative privileges, but in Windows Azure it runs under a restricted Windows service account.

An application running as a hosted service in Windows Azure or in the compute emulator runs in a job object. Job objects cannot be nested, so if your code is running in a job object, it may not successfully run. Try running your code without the job object if it is failing for unknown reasons.

In previous versions of Windows Azure, network policy restrictions were enforced by Code Access Security under Windows Azure partial trust. In this environment, a violation of network policy results in a security exception. Windows Azure full trust now enforces network policy restrictions by using firewall rules. Under full trust, a violation of network policy causes the connection to fail without an error. If your connection is failing, your code may not have access to a network resource.

A web role is automatically configured to point to a page named Default.aspx as the default application page. If your application uses a different default application page, you must explicitly configure the web role project to point to this page in the web.config file.

The Windows Azure Managed Library defines a Role class that represents a role. The Instances property of a Role object returns a collection of RoleInstance objects, each representing an instance of the role. This collection always contains the current instance. Other role instances are available by using this collection only if the role has defined an internal endpoint, which is required for the role instances to be discoverable. For more information about role communication, see Overview of Enabling Communication for Role Instances.

If you are using the Windows Azure Storage Client Library to work with the Table service, your service may throw a StorageClientException with the error message "Unexpected Internal Storage Client Error" and the HTTP status code 306 (HttpStatusCode.Unused). If this error occurs, you must create a new TableServiceContext object and retry the operation. This error can happen when you are calling one of the following methods:

• TableServiceContext.BeginSaveChangesWithRetries
  
  
• TableServiceContext.SaveChangesWithRetries
  
  
• CloudTableQuery.Execute
  
  
• CloudTableQuery.BeginExecuteSegmented
  
  

If you continue to use the same TableServiceContext object, unpredictable behavior may result, including possible data corruption. You may want to track the association between a given TableServiceContext object and any query executed against it because that information is not provided automatically by the Storage Client Library.This error is due to a bug in the WCF Client Library version 1.0. The bug will be fixed in version 1.5.

If CSPack worked to package your application using the Windows Azure SDK 1.1, but does not work after you upgraded to the Windows Azure SDK 1.2 or later, the problem may be that you have not correctly specified the .NET target framework version for CSPack. CSPack assumes that your service code has been compiled under .NET 3.5 by default. If your code has been compiled under .NET 4, you must provide that information on the command line.

To set the .NET target framework version to 4, create a role properties file and include the TargetFrameWorkVersion setting with a value of v4.0. Run CSPack with the /rolePropertiesFile option set to point to the location of the role properties file. For more information about using CSPack, see CSPack Command-Line Tool.