"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.Disp开发者_开发技巧atch() 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 :)
Installing .Net Framework 3.5 fixed this exact problem for me.
Hope that helps! Sorry I can't offer any additional insight as to what exactly was going wrong with cassini, but I suspect it was missing a library or two.
====
Update: Seems to have helped (no longer crashes on the first request), but upon further use I've come across another place where the same error crops up.)
====
Update: And now I can't recreated it anymore. Best of luck, and if you discover any more please post!
The thing that gets my attention is Win2008R2 and Cassini.
I'm just guessing, but it makes me think that it could be a permission issue.
Is it possible that your Win2008R2 machine is locked down more than your average developer machine (the average developer machine being XP / Vista / Win7 etc).
Perhaps Cassini when launched under your user account on Win2008R2 does not have enough permission to do its thing. Perhaps it cannot open ports? But I wouldn't think a port issue would cause a crash. Or perhaps it doesn't have access to the temporary directories it needs?
Perhaps your user account is denied the permission to debug on the local security policy? But i'm not an admin, so i'm not certain on this.
Maybe try launching visual studio as an Administrator (just incase, to help you investigate the problem).
Or perhaps try starting your site without debugging to help see if it's some sort of permission issue with debugging processes.
I came across this, it's from some time ago talking about Windows 7 and Cassini. http://msmvps.com/blogs/rfennell/archive/2009/01/24/problem-hosting-wcf-using-cassini-on-windows-7.aspx But it may not of been fixed.
精彩评论