With Windows Azure Tools, why do I receive Invalid access to memory location?

Question

I have the following installed:

• Visual Studio 2010
• Windows Azure Tools, v1.5
• Windows Azure SDK, v1.5

When I attempt to debug a "Web Role", I receive the following error: "Windows Azure Tools: Invalid access to memory location"

This shows up in the "General" output of Visual Studio. When this happens, it cancels the build/debugging session. This does not happen every time. If I try again, it might work.

Memory looks like this:

• Total: 8061
• Cached: 969
• Available: 1468
• Free: 524

Roughly 81% in use.

So, the question is, why am I receiving this error?

Answer 1

I’ve documented the cause and solution for this bug here: http://blogs.msdn.com/b/cie/archive/2013/10/31/compute-emulator-invalid-access-to-memory-location.aspx

The solution is to install Windows 8.1 or install the KB 2588507 hot fix (http://support.microsoft.com/kb/2588507/en-us) to correct the kernel address-conversion routines in older 64-bit versions of Windows.

Answer 2

Although it sounds like sacrificing a dead chicken over my PC I tried the instructions here:

http://old.stevenharman.net/blog/archive/2008/04/29/hacking-visual-studio-to-use-more-than-2gigabytes-of-memory.aspx

to persuade my Visual Studio 2010 to stop giving me memory-related errors of this kind. Worked a charm, and appeared to improve general performance of Visual Studio altogether.

However, as with most voodoo chants, your mileage may vary. Take backups.

Answer 3

I too have seen this error when attempting to debug. It appears to be when Visual Studio has problems starting the Compute and / or Storage Emulators. Starting them manually before running the application seems to do the trick.

I cannot begin to knowledgeably speculate on what causes this error, however since a lack of understanding has rarely stopped me before: my working hypothesis is that it may well be memory related since this error only seems to appear if Visual Studio (2010) has been running for a while (ie once VS's memory usage has had time to creep up).