Reputation: 5749
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:
Memory usage of the worker process:
Upvotes: 2
Views: 9680
Reputation: 5749
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.
Upvotes: 1
Reputation: 10493
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.
Upvotes: 1
Reputation: 4725
It's trying to compile, does it need writable access to some temp directory.
Upvotes: 0