Compartilhar via


Compiler Error Message: CS0016: Could not write to output file 'c:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET FilesMyAppfadda49ebbdb0b87eqdatzch.dll' -- 'Access is denied.'

What I like about the above error message is the part which says 'Access is denied.' These are some of the easiest issues to fix!! Right?? Well in most cases 'Yes'. All you have to usually do is give the Process Account or Impersonating thread identity required NTFS access to the resource. The reason I like working here in PSS is because you get to work on issues which will blow your mind (EVERYDAY). Most customers would have already Googled for a solution and tried an extensive list of things trying to fix the issue. If they haven't already done that, then they are calling because the WebSite is down and the business impact $$$$$$$$ is "HUGE".

          In this case the customer was of the former type. He had tried everything to fix the issue but to no avail. To give you a little background on the issue, the Web Server was a Windows 2003 SP1 server(IIS 6.0) running an ASP.NET WebService. The App used to work fine until it threw the above error. According to the customer, the only way to recover from the problem was to repeatedely reboot the machine and the error would go away. I had never heard of anything like this before. Neither have the 3 Engineers who worked on this issue before engaging me to have a go at the problem heard of anything like this. The typical way to troubleshoot this problem would be to verify that all the permissions and policies were in place as per the knowledge base article Process and request identity in ASP.NET: https://support.microsoft.com/kb/317012 .

The AppPool identity was the default "Network Service" account. After verifying kb317012 a dozen times we were still getting the error. The bizzare part was that "Network Service" account had Full Control on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder but running Filemon would still show Access Denied for the "Network Service" account on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder. The Engineers had tried various way to troubleshoot the problem. They tried changing the AppPool Identity to a domain account but this resulted in the same error and Filemon now showed Access Denied for the domain account. This is about when I came in and I requested the customer to allow us to view his desktop via a Live Meeting.

Working here for over 2 yrs has taught me never to trust anyone, especially customers. In this case I didn't trust my fellow Engineers as well so I went through all the same troubleshooting steps they had done (I dont like making assumptions without hard facts). This dosen't go down too well with customers as nobody wants to try the same steps repeatedely, if you already know its not going to help. While I was checking the NTFS permissions for the Network Service account on "C:\Windows\Temp" something caught my EYE and I made sure I took a PRINTSCREEN so that I can share this information with you :) 

RESOLUTION
===========
If you notice clearly, the "C:\Windows\Temp" location is not a folder but a Mounted Drive. If you then click the Security Tab for "C:\Windows\Temp" you can see the Network Service account present with FULL CONTROL. Instinct tells me that this may be related to the issue so the next logical step would be to isolate the problem and see if changing the "C:\Windows\Temp" helps.

I changed the values of the TMP and TEMP System Environment variables to point to "C:\TEMP" instead of "C:\Windows\Temp" and this resolved the issue.

IIRC they had the "C:\Windows\Temp" location set up as a mounted drive to store huge number of files there which were getting writin by some other application. Somehow ASP.NET didnt like it.

Now you might still wonder, why do we get the error if all the permissions seem to be in place?? As much as I would have liked, I couldn't invesitigate further since we already had an acceptable solution as it is not worth the time and effort to find out why mounted volumes are causing the issue.

Comments

  • Anonymous
    June 07, 2007
    Hi there! Thank you very much for your help! This has helped me solve a problem that was very annoying and confusing. Thanks, once again! All the best, Irinel

  • Anonymous
    July 10, 2007
    THANK YOU THANK YOU THANK YOU!!! I had to meet a deadline and my website could not start because ASP could not create ONE file in the Temporary ASP.Net directory even though the permissions were correct. I never would have known to look at the WindowsTemp folder if not for this blog. It turns out that I had two SIDs in the ACL that could not be resolved and I deleted them. I also set full control for Network Service because I believe that is the account that writes to the temp folder. I can't actually double check that right now, so don't quote me on that.... Anyway, thank you so much. This was a lifesaver.

  • Anonymous
    July 16, 2007
    I think this is a very good article. I have this problem and look all over the web for resolution. My error message was "There is not enough disk space". Do you think it is the same cause??? thanks

  • Anonymous
    July 19, 2007
    This works on my server...while all other solutions on the web failed... I used to partition HDD and customise shell folders' locations...and .NET web-apps / IIS seemed not comfort within my server settings. Thank you very much!

  • Anonymous
    September 12, 2007
    We are using .Net Framwork 2.0 and I received a simelar error message.  This same solution worked for us.  Thanks!!!

  • Anonymous
    October 02, 2007
    The comment has been removed

  • Anonymous
    November 05, 2007
    We had the same problem.  The environment was set up to use E:Temp for the temp folder, but the folder had never been created on E.  Created the folder and it worked.

  • Anonymous
    November 06, 2007
    I've tried this and it still doesn't work. Please help me fix this. Our website has been working fine. I went to make a change on the website when this error started occurring. I've checked the permissions and had our IT NT guy look and he verified all permissions. PLEASE HELP ME! jignesh.shah@pni.com

  • Anonymous
    November 07, 2007
    Hey Jignesh,   Can you copy paste the entire stack trace? Thanks, Vignesh

  • Anonymous
    February 03, 2008
    Thank you so much..... This has helped me to solve the problem.

  • Anonymous
    March 05, 2008
    Thank you so much..... This has helped me to solve the problem.

  • Anonymous
    April 09, 2008
    I am having the same problem with a Sharpoint 2.0 install. I have tried changing the temp and tmp variables and checked permissions but no help. Any other suggestions as to what else I can try?

  • Anonymous
    April 09, 2008
    Please ignore my first post.  The power of REBOOT is amazing. I got it to finally work with your solution.  Many, many thanks.

  • Anonymous
    June 16, 2008
    The comment has been removed

  • Anonymous
    June 25, 2008
    Hi Linsen,    You would get this error even after you run the aspnet_regiis -i command. All this command does is a) Reconfigures IIS mappings to handle extensions like .aspx, .asmx etc. b) Creates ASPNET account if missing. c) Ensures ASPNET account has minimum privileges for certain common folders.

  • Anonymous
    August 18, 2008
    This solved a similiar issue with trying to reference a web service in VS 2005 on a Vista machine. Just gave the NETWORK SERVICE rights to c:windowstemp folder and viola, it was resolved. Much appreciated for pointing me in the right direction!

  • Anonymous
    September 02, 2008
    Here's a real fix: Look at all the drives and mount points for TEMP and make sure Network Service has full access to ALL of them. I had to grant Network Service rights to BOTH C:TEMP and T: for it to work (I'd already moved C:WINDOWSTEMP to C:TEMP) since the drive was mounted both places. To figure this out, I ran SysInternal's procmon filtered for csc.exe and looked for the permission error. It tried to write to C:TEMP (which it has permission to) but then tried to write to T: (which it didn't). Looks like CreateFile is translating the mount points over to drive mappings somewhere, so you need to grant identical permission to each mount point/drive.

  • Anonymous
    September 24, 2008
    The comment has been removed

  • Anonymous
    October 05, 2008
    Hello guys, im having the same problem with Asp.net 2 , all the above solution did not work , anu help please. mu application created in VS2008 my OS is windows server 2003 and im using IIS6 and .net 2 . please any help will appreciate.

  • Anonymous
    October 11, 2008
    Hello Guys,           I have the same issue in ASP.Net 2.0. As per the Vignesh's statement I checked the "Temp" directory securities in c:windows . Its is not showing as "Mounted Volume". Its showing as "File Folder" I gave full rights to that Folder for "ASP.Net" and "Nettwork service" account. I am using "Administrator" account for windows login. Still the problem persists. Eventhough I tried to change the Environment varible to locate in "C:Temp" instead of C:WINDOWSTEMP", but its not solving this issue. Can you please share the solution if u have anything. Please.......... Thanks in advance.... Saravanan.S

  • Anonymous
    October 31, 2008
    The comment has been removed

  • Anonymous
    January 06, 2009
    Thank you! It helped a great deal.

  • Anonymous
    January 18, 2009
    Had this issue on Windows Vista for a .NET 2.0 application. Jeff's solution to grant Network Services permissions to WindowsTemp resolved my issue as well. Thanks!

  • Anonymous
    March 01, 2009
    Hi, I'm using McAfee VirusScan Enterprise with highly secured settings and found that it was McAfee which was preventing VS to create new file in Windows directory. Thanks for sharing this anyway :)

  • Anonymous
    March 23, 2009
    The comment has been removed

  • Anonymous
    March 24, 2009
    Hi How you have changed the values of the TMP and TEMP System Environment variables to point to "C:TEMP" instead of "C:WindowsTemp"   Thanks

  • Anonymous
    March 24, 2009
    I created Network services at windowstemp folder, while creating there is an option called location, I am confused which location I must choose? later I gave full control. still I am getting the same error

  • Anonymous
    March 24, 2009
    Great fix. Was about to give up and take reinstallation route before coming across this entry. Stupid verbiage of the error message was misleading me in all directions. Though in my case temp was not a mounted drive or no permission issues foresee, I just went ahead and changed the dir and it did the magic

  • Anonymous
    October 22, 2009
    Thanks a lot for the info... It worked for me.

  • Anonymous
    February 20, 2010
    Thanks, worked for me. In my case, the server was missing the TMP and TEMP system variables.  As soon a I directed them to C:WindowsTemp, that did the trick. There were user variables for TMP and TEMP pointing to the default locations.

  • Anonymous
    April 11, 2010
    Peradventure you have tried granting full access to NETWORK SERVICE on C:temp as many having suggested and no luck. You may need to also grant NETWORK SERVICE account Full Access to C:Windowstemp Hope this helps!

  • Anonymous
    November 09, 2010
    I gave the NETWORK SERVICE account full control to the location of TEMP and TMP environment variables and this fixed it for me.

  • Anonymous
    April 01, 2011
    Hi Id like to know if it is possible to writedata to file. I am using version 2.0 and when I compile code it complains that it does not know filestresm and debugger.

  • Anonymous
    December 02, 2012
    thank you very much i solve my problem

  • Anonymous
    May 23, 2013
    The comment has been removed

  • Anonymous
    November 21, 2013
    Thank You! Worked a treat! Found a previous tech had created an additional temp folder without appropriate permissions.

  • Anonymous
    May 22, 2014
    That's very sloppy design for the CSC... If it tries to write to C:WindowsTemp it SHOULDN'T ever say it can't write to C:WindowsMicrosoft.NETFramework...Temporary ASP.NET Files... ! Anyway, is this configurable anywhere? Since i want CSC to write only to C:TempVS while other programs write in their own designated Temp folders.

  • Anonymous
    May 13, 2015
    This is a great help!! Saved my day.. Thanks a lot !!

  • Anonymous
    July 01, 2015
    Do this in a dos promt as administrator c:windowssystem32icacls c:windowstemp /grant "IIS_IUSRS":(OI)(CI)M