Could not find file ‘C:WINDOWSTEMP..dll’

Artículo
04/18/2009

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: https://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 https://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: https://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: https://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

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

(refer to https://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: https://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. smile_regular

Andrea

Comments

Anonymous
April 18, 2009
PingBack from http://microsoft-sharepoint.simplynetdev.com/could-not-find-file-%e2%80%98cwindowstempdll%e2%80%99/
Anonymous
January 07, 2010
I have the same problem on a web site running under a custom user account.Giving Read/Write or Modify access rights does not solve the problem. However giving Full control does solve the problem. So this is definitely a privilege problem. It would be interresting to know exactly which privileges are mandatory for the whole process.I remember a similar problem with source safe's Analyse utility that requires the advanced rights 'Delete Subfolder and files' and 'Change Permissions' (WRITE DAC) to work properly !
Anonymous
March 22, 2011
Hi,You can find this solution to the above problem faced by you rather useful than u think.after creating the deployment/setup project and naming it "execreation" by adding it to the solution.right click on the execreation exefile that appears in visual studio IDEClick add then select project output.In the add project output group window select the project u wanna add from the project dropdown.Select the primary output from the list just below the project label.Leave all the remaining options as it is.Now add the files that the application when run on other system could not find as u mentioned in above figure"C:WINDOWSTEMPhgza30lw.dll" by browsing to the drive in the development system only.These files need to be added to the "execreation" by right clicking on it in solution explorer->ADD ->FILE and browse to the files what ever needed by the application ( as per your requirement browse for C:WINDOWSTEMPhgza30lw.dll)like wise go on adding the files to the execreation up to the requirement.Now,write the following code in the name spcae after the end of the classstatic class FileHelper { #region Get .dsx Files in AutoRecordChanger Programfiles folder. /// <summary> /// Get .dsx Files in AutoRecordChanger Programfiles folder. /// </summary> /// <param name="drive"></param> /// <returns>dsxArray which is a string array.</returns> public static string[] getFilesRecursive(string drive) { // 1. // Store results in the file results list. List<string> result = new List<string>(); // 2. // Store a stack of our directories. Stack<string> stack = new Stack<string>(); // 3. // Add initial directory. stack.Push(drive); // 4. // Continue while there are directories to process while (stack.Count > 0) { // A. // Get top directory string dir = stack.Pop(); try { // B // Add all files at this directory to the result List. if (dir.Contains("execreation")) { result.AddRange(Directory.GetFiles(dir, "*.dsx")); } // C // Add all directories at this directory. foreach (string dn in Directory.GetDirectories(dir)) { stack.Push(dn); } } catch { // D // Could not open the directory } } string[] dsxArray = result.ToArray(); return dsxArray; } #endregion }In the main method or wherever the file is being called / or simply for the use of theabove codestring [] dsxArr = FileHelper.getFilesRecursive(@"C:");Enjoy
Anonymous
May 11, 2012
The comment has been removed
Anonymous
May 14, 2014
I kown another method ,that is restarted "world wide web publishing servvie" service

Compartir a través de

Could not find file ‘C:WINDOWSTEMP..dll’

Comments

Recursos adicionales