I have a brand new VS2010 installed on a Win2008R2 machine.
I started getting this error when debugging a WCF service project:
“Attempted to read or write protected
memory. This is often an indication
that other memory is corrupt.”
When I started developing a web site a week later, this became consistent – I can’t debug it.
The stack dump reads:
at
Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection
conn) at
Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object
acceptedSocket) at
System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object
state) at
System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback
callback, Object state, Boolean
ignoreSyncCtx) at
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at
System.Threading.ThreadPoolWorkQueue.Dispatch()
at
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I tried searching online, and some recommend turning off the “Suppress JIT Optimizations” in the Debugging options – this dos not seem to make a difference.
Clearly the problem is with the built in web server. But am I doing something wrong? Is there something I can do? Or is this a known bug?
Thanks for your time,
Guy
Update 12/31: Today I tried using CassiniDev as a replacement to the original VS2010 WebServer – exact same result. My suspicion is that there’s some internal conflict between VS2010, Windows Server 2008R2 and maybe the fact that it’s a 64 bit OS. I switched to using IIS as my debug server – and that seems to work, with some annoying side effects.
My conclusion: do not use a 64 bit server system as your dev machine. Develop on 32bit – deploy to 64bit.
Side conclusion: there are some scenarios Microsoft’s QA doesn’t test.
Well, here’s the sad truth, and I verified it with someone who works for Microsoft, with these very same technologies. I just triggered some sort of Cassini bug. He suggested I try installing VS2010 SP1 beta (which I cannot do since my code is due in production). His other suggestion was to try IIS Express. MS is trying to move people over to IIS Express and provides it as part of their web platform installer – so it stands to reason they will not be spending too much time plugging Cassini bugs.
Since I was using a 2008 server, I just added IIS (takes less than a minute), created a virtual directory (the VS project page allows you to do it with one button click) and I’m now successfully debugging on IIS. Not the result I wanted, but you can’t always get what you want 🙂