Rory Primrose

Learn from my mistakes, you don't have time to make them yourself

View project on GitHub

Workaround for Azure SDK Invalid access to memory location error

Posted on March 19, 2012

There is an issue with the Azure 1.6 SDK that I often hit when I run a cloud project. I get around 3-5 debug sessions with my cloud project before Visual Studio starts throwing an Invalid access to memory location error.image

This issue seems like it is hitting many other people as well. This is a significant pain point for working with Azure projects and there is currently no suitable workaround or fix that I can find. Sometimes shutting down the emulator and trying again works. Most often however, the IDE needs to be recycled. Having to do this each fifth F5 is a productivity killer.

It seems that the most reliable information out there is that the issue is caused by addins/extensions in Visual Studio. This is consistent with my experience of running automated integration tests as defined in my previous posts. I quickly encounter this problem running F5 from the IDE, yet launching Azure and IISExpress for integration tests does not suffer from this error. This leads me to a reliable workaround for this issue based on my integration test implementation using the External Tools support in Visual Studio to manually launch the emulator.

Configuring External Tools

We need to add three External Tools entries. These are for launching the compute emulator in the Debug configuration, another one for the Release configuration and finally the storage emulator.image

Click Tools –> External Toolsimage

First up is to configure launching the emulator for the debug configuration.

  1. Click Add
  2. Enter the title for running the compute under debug
  3. Enter the command as C:\Program Files\Windows Azure Emulator\emulator\csrun.exe
  4. Enter the arguments as /run:"$(SolutionDir)[YourCloudProjectName]\csx\Debug";"$(SolutionDir)[YourCloudProjectName]\bin\Debug\ServiceConfiguration.cscfg" /launchBrowser
  5. Setting the Initial directory is optional, but $(SolutionDir) is as good as any setting
  6. Check Use Output Window and click Apply

Unfortunately the ExternalTools window does not process the $(ConfigurationName) macro like the build events function does. This is why we need an entry for each build configuration (typically Debug and Release).

Create a new External Tools entry for the compute emulator to load the Release build. It will have the same configuration except that references to Debug are replaced with Release.

Create a new External Tools entry for the storage emulator. The arguments for this field are /devstore:startimage

The requirement for a separate entry for the storage emulator is unfortunate. It is required because the csrun.exe does not support command line parameters for both the compute emulator and the storage emulator in the one execution.

Attaching the debugger

You can configure csrun to attach to the debugger using the /launchDebugger switch. I did not want to use this switch because it will open new instances of the debugger (typically devenv.exe) for each role instance (web and worker). This is unhelpful because I want to use the existing Visual Studio instance. I also found that the browser could not hit the compute instance anyway when the debugger was attached in this way (this could be just a timing issue though).

The easiest way around this is to just attach to the process manually.

Click Debug –> Attach to Process…image

Find w3wp.exe and click Attach.image


This workaround only spins up the compute emulator or the storage emulator. It does not do any of the following:

  • Build/Rebuild your projects
  • Request shutdowns of the emulators
  • Attach a debugger