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: .

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 🙂 

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 (39)
  1. Irinel says:

    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,


  2. Andrew in Afghanistan says:


    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.

  3. 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???


  4. TiuDavid says:

    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!

  5. Martin Loubser says:

    We are using .Net Framwork 2.0 and I received a simelar error message.  This same solution worked for us.  Thanks!!!

  6. Parham says:

    Hi Prof.!

    This has helped me to solve the problem.

    Thank you very much for your help!

    Thanks, once again!

    Thanks, twice!

    Thanks, ……..!

    it really wanted to kill me!!!!!!!!!

    All the best,


  7. Jason Fransella says:

    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.

  8. JIGNESH SHAH says:

    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.


  9. Vignesh says:

    Hey Jignesh,

      Can you copy paste the entire stack trace?



  10. ydedys says:

    Thank you so much…..

    This has helped me to solve the problem.

  11. Ezequias says:

    Thank you so much…..

    This has helped me to solve the problem.

  12. Chris says:

    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?

  13. Chris says:

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

  14. linsen mathew says:

    i don’t think this is the perfect solution…guys please try this step…

    1. On the Start menu (Windows),  click Run.

    2. In the Run dialog box, enter cmd.

    3. In the Command Prompt window, enter C:WINDOWSMicrosoft.NETFrameworkv1.1.4322aspnet_regiis.exe -i.

    make suitable changes for 2.0 and above 🙂

    got this from a url…

  15. Vignesh says:

    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.

  16. Jeff says:

    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!

  17. Mark Woodruff says:

    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.

  18. Ian Murphy says:

    I’ve just spent several hours on a problem on a WSUS instalation at a client site. I’m fairly used to resolving this type of problem but in this case I was just banging my head against the wall.

    Upon reading your I thought I’d check the temp directory. It was a normal directory and not a mounted device. However I decided to check the TEMP variable was ok…. and there was my problem. A colleague had decided to move the temp directory to another drive without telling anyone. The security setting for Network serice was readonly and consequently stopped working.

    So, the moral is – Never trust anyone.


  19. Noor says:

    Hello guys,

    im having the same problem with 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.

  20. Saravanan.S says:

    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….


  21. Karthikraj says:

    Oh my god. This was an excellent solution. I had been breaking my head for 3 weeks before i stumbled across this suggestion. Excellent help vicky. I appreciate it.



  22. Rahul says:

    Thank you! It helped a great deal.

  23. McKinney says:

    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.


  24. Waseem says:


    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 🙂

  25. Kashif Nizam says:


    Yeah, Waseem you save my life, I was about to commit suicide! The demon was McAfee. Out dumb IT dept applied new polices or something and it created this error.


  26. san says:


    How you have changed the values of the TMP and TEMP System Environment variables to point to "C:TEMP" instead of "C:WindowsTemp"  


  27. San says:

    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

  28. SR says:

    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

  29. Nikita says:

    Thanks a lot for the info…

    It worked for me.

  30. Matt says:

    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.

  31. Light Kimon says:

    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!

  32. Dino says:

    I gave the NETWORK SERVICE account full control to the location of TEMP and TMP environment variables and this fixed it for me.

  33. Nhlanhla says:


    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.

  34. Hitcher says:

    thank you very much i solve my problem

  35. priyeshkadge says:

    this helped me…

    Create a temporary folder under %Systemroot%, and then name it Temp.

    Grant full permissions on the Temp folder to the aspnet user account in .NET Framework 1.0 or to the NETWORK SERVICE user account in .NET Framework 1.1.

    Right-click My Computer, and then click Properties.

    On the Advanced tab, click Environment Variables.

    Select the TEMP variable under System variables, and then click Edit.

    Type %SystemRoot%TEMP in the Variable Value box, and then click OK.

    Repeat steps 5 and 6 to edit the TMP variable. Click OK two times.

    Click Start, and then click Run.

    To reset Internet Information Services (IIS), type iisreset on the command prompt.

  36. BINGO! says:

    Thank You! Worked a treat! Found a previous tech had created an additional temp folder without appropriate permissions.

  37. C says:

    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.

  38. Karthik says:

    This is a great help!! Saved my day..

    Thanks a lot !!

  39. Søren Møller DK. says:

    Do this in a dos promt as administrator

    c:windowssystem32icacls c:windowstemp /grant "IIS_IUSRS":(OI)(CI)M

Comments are closed.

Skip to main content