Could not find file ‘C:WINDOWSTEMP..dll’
Sometimes customers open technical support cases because of this (apparently simple) issue:
“System.Web.Services. Protocols.SoapException: Server was unable to process request. --> System.Io.FileNotFoudException: Could not find file ‘C:\WINDOWS\TEMP\hgza30lw.dll’.[…]”
When you use an ASP.NET web service/client, a temporary serialization assembly is generated by it several times, in particular a serialization code is first generated and csc.exe compiler is launched in order to create a temp assembly. The aforementioned error describes a failure in the temp assembly generation, which could be a compilation error, but also a trouble in creating the csc.exe process.
If you create a serialization assembly by using sgen.exe, you will avoid running csc.exe because you no longer need to compile temp serialization code: as a matter of fact the generated code is always the same, so it’s much better to create it once and for all from performance point of view. I generally recommend to make a pre-compiled serialization assembly for performance reasons through sgen.exe: http://msdn.microsoft.com/en-us/library/bk3w6240.aspx. But be aware of this: “These generated assemblies cannot be used on the server side of a Web service. This tool is only for Web service clients and manual serialization scenarios. ”. You can’t use sgen’d assemblies on the web service side.
The error could also be caused by other software applications (for example, antivirus) which perform some kind of actions in the c:\WINDOWS\TEMP folder. To easily check this, you can configure another folder for temp serialization assemblies compilation from .NET 2.0 Service Pack 1 on. I recommend to have a look at http://blogs.msdn.com/drnick/archive/2008/06/16/serialization-temporary-assemblies.aspx to understand how to do that.
Another important troubleshooting step is to enable xmlserialization tracing in order to detect possible compilation errors of temp assembly: http://support.microsoft.com/kb/823196/en-us. Just add the following entry to your WCF service config file:
<configuration> <system.diagnostics> <switches> <add name="XmlSerialization.Compilation" value="4"/> </switches> </system.diagnostics> </configuration>
The NETWORK SERVICE must have access to the c:\windows\temp folder with read/write permission. BTW the compilation traces are generated in the user temp folder and, if we’re running in IIS, it will be c:\temp (%SYSTEMROOT%\Temp). The traces won’t be written in c:\windows\temp, but in c:\temp. From the traces you could get useful info to understand if you either have any compilation error or the csc.exe process can’t be launched.
If you realize the csc.exe process didn’t get started, based on my experience this kind of problem could also be due to a resource leak: once the ASP.NET worker process is consuming to much resourse, the temp assembly build process could fail.
It might be you have too many application pools/web applications and/or you’re overloading the desktop heap.
You can monitor the desktop heap usage with a tool named DHeapMon.exe. This good post by a colleague of mine explains how to install it: http://blogs.msdn.com/alejacma/archive/2008/07/29/how-to-use-dheapmon-exe-to-troubleshoot-desktop-heap-issues.aspx
Another option could be represented by tuning the desktop heap settings for testing purposes (we can essentially increase the desktop heap space available for the non interactive desktop), but I would recommend this test only on a testing environment, as those settings are machine wide and could affect other application’s behavior.
You could check the registry values for the following keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
(refer to http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx for more details)
Last but not least, make sure the "World Wide Web Publishing Service" the "Allow service to interact with desktop" checkbox on the “Log On” property page is deselected.
If you enable “Allow service to interact with desktop”, the worker process will be tied to the windows station “Winsta0” and, to cut a long story short, any user logon/logoff could trigger such a problem, getting w3wp.exe unable to run new processes (the new process we should be able to run is csc.exe). If you want to know more about “windows station”, the article is always the same: http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx.
If you face this problem again, I do hope you will find the root cause listed in this post.