"Out of memory" exception on call to web service

Question

I have an ASP.NET web application that calls a .NET DLL, that in turn calls a web service. The web service call is throwing an exception:

Unable to generate a temporary class (result=1). error CS0001: Internal compiler error (0xc00000fd) error CS0003: Out of memory

Stack Trace: at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies) at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence) at System.Xml.Serialization.XmlSerializer.GetSerializersFromCache(XmlMapping[] mappings, Type type) at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Type type) at System.Web.Services.Protocols.SoapClientType..ctor(Type type) at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()

I should mention that this is the first time I have executed this particular bit of code on this PC (I recently did a Windows reformat/reinstall) -- which makes me think it is a problem with the environment (the same application runs fine on our test and production servers). But I'm stumped as to the cause.

---

Some additional details to answer follow-up questions:

• This is a real PC (not a VM).
• I'm running .NET 3.5 on IIS 7. Our production servers are IIS 6, but it has worked correctly on IIS 7 before.
• The PC has 2 GB of RAM with plenty of that free.
• I haven't changed any of the machine.config settings, nor any of the web.config settings related to process model, compilation, memory usage, etc.
• The local IIS_IUSRS group has read/write permissions for the "Temporary ASP.NET Files" folder.
• I checked the application pool settings: both private memory and virtual memory are set to 0 (no limit).

Memory usage of the worker process:

• I recycled the worker process to get a clean slate and then hit an ASP.NET page in the application...Task Manager shows 22 MB used.
• I then hit the event that makes the web service call and the memory usage shoots up to about 150 MB, levels off, then I get the exception.

Answer 1

Thanks for adding more detail.

Have a look at this link: http://support.microsoft.com/?kbid=908158
It's similiar to the problem you're having.

It recommends the following: To resolve this issue, grant the user account the List Folder Contents and Read permissions on the %windir%\Temp folder.

This one:
http://club.workflowgen.com/scripts/club/publigen/content/templates/show.asp?P=53&L=EN

recommends:
To avoid this problem, give read/write priviledges for the Temp folder to the ASPNET account. When ASP.NET Web Services process WebMethods, the identity that is used most frequently to gain access to the system Temp folder is the local ASPNET account, which is the default account under which ASP.NET applications run.

However, if you have configured your application to use impersonation in its Web.config file, the thread can also use the identity of any caller. If this is the case, all potential calling identities must have read/write priviledges to the Temp folder. A likely calling identity is the Internet Information Services (IIS) application's anonymous account (typically the ISUR_xxx account). The thread may also use the IWAM_xxx account or NETWORK SERVICE.

Answer 2

It's trying to compile, does it need writable access to some temp directory.

Answer 3

Well, I'm not sure exactly why this worked (which is frustrating), but I did come up with something...

My previous install of Windows was 32-bit, but when I rebuilt my PC recently, I went with the 64-bit version. So, I changed the "Enable 32-Bit Applications" setting on my application pool in IIS to "True", and everything seems to work fine now.

The DLL and the web site itself are configured to compile as "Any CPU", so they shouldn't have caused any problems on Win64. And the "out of memory" error is still a bit perplexing (and unhelpful). If anyone has any ideas, you get the "accepted" points.