tags:

views:

815

answers:

3

I'm getting an AV when I hit a COM interop ASP page (that calls managed .NET code). Feels like this has something to do with IIS 7 / Windows 2008.

Google can't figure this out. Any ideas?

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

   at System.Web.Hosting.UnsafeIISMethods.MgdGetSiteNameFromId(UInt32 siteId, IntPtr& bstrSiteName, Int32& cchSiteName)
   at System.Web.Configuration.ProcessHostConfigUtils.GetSiteNameFromId(UInt32 siteId)
   at System.Web.Configuration.ProcessHostServerConfig..ctor()
   at System.Web.Configuration.ProcessHostServerConfig.GetInstance()
   at System.Web.Configuration.ServerConfig.GetInstance()
   at System.Web.Caching.CacheMemoryPrivateBytesPressure.ReadConfig(CacheSection cacheSection)
   at System.Web.Caching.CacheMemoryStats.ReadConfig(CacheSection cacheSection)
   at System.Web.Caching.CacheCommon.ReadCacheInternalConfig(CacheSection cacheSection)
   at System.Web.HttpRuntime.get_Cache()
A: 

This isn't an answer, but just to say my shop is seeing the same thing both on Windows Vista (x64) and Windows Server 2008 (x64). When the application pool is configured to run in 64-bit mode, the first COM call from ASP produces a similar stack trace.

The really weird part for us is it goes away on the 2nd and later calls. So it happens only once after the app pool recycles, then seems to work fine.

We have been unable to resolve this issue as well.

Chris Eldredge
A: 

I ran into the same issue after upgrading to Windows 7 (and IIS7) A WCF service that was previously working started to get this error.

To fix, I went into the Build properties of my projects (Project/properties/Build Tab) and changed the Platform Targer to "x86". Then the problem was gone.

Jeff
A: 

Changing the target cpu to x86 resolved me issue too.

Alok