Classic ASP errors with current identity does not have write access to c:\windows\microsoft.net\framework\v4.0.30319\temporary ASP.NET files

Ramirez, Rose 0 Reputation points
2026-09-11T22:02:46.3+00:00

Within IIS 10, classic ASP website, I cannot find any .NET code in this ASP files causing the authentication error. We have tried all the suggested options by giving the user permissions to the folder, removed the user from the website, cleared the cache and it still does not work. The user account has been give permissions to c:\Windows\temp. What more can I do? I would like assistance to resolve the issue. Thank you

Windows development | Internet Information Services
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tom Tran (WICLOUD CORPORATION) 5,945 Reputation points Microsoft External Staff Moderator
    2026-09-14T02:47:47.0166667+00:00

    Hi @Ramirez, Rose ,

    The error does not necessarily mean the .asp files contain .NET code. If the application pool uses the Integrated pipeline, ASP.NET modules can also participate in Classic ASP requests. Microsoft documents this behavior in Application Pools in IIS.

    I would suggest checking the following first:

    1. Open the application pool’s Advanced Settings and note its Identity, .NET CLR Version, and Managed Pipeline Mode.
    2. Check the complete error message for the identity shown in parentheses.
    3. If the site is entirely Classic ASP and does not use managed modules or child ASP.NET applications, test it in a dedicated application pool with .NET CLR Version set to No Managed Code.
    4. If managed processing is required, grant the identity shown in the error read and write access to the exact folder named in the message: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

    C:\Windows\Temp is a separate directory, so permissions there do not address this particular error. Microsoft lists the required permissions for the ASP.NET compilation folder in ASP.NET Required Access Control Lists.

    If the issue remains, please share the complete error and stack trace with sensitive details removed, along with the three application pool settings above. That should show whether unnecessary managed processing is being loaded or the actual worker identity still lacks access.

    Was this answer helpful?

  2. Bruce (SqlWork.com) 85,441 Reputation points
    2026-09-13T15:27:46.82+00:00

    If your classic asp does not use .net, you probably configured .net pipeline which does. Edit the pool account and set the clr version to no managed code and pipeline mode to classic. Also under advanced settings enable 32 bit applications

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-09-11T22:03:07.15+00:00

    For a Classic ASP site, that path usually points to a permissions problem on a temporary folder used by the worker process or impersonated identity, not necessarily to actual .NET code inside the ASP pages.

    Try this end-to-end path:

    1. Identify which identity is actually failing
      • Use Process Monitor or FileMon and reproduce the error.
      • Filter for w3wp.exe and look for ACCESS DENIED entries.
      • This confirms whether the failing identity is the Application Pool identity, IUSR, NETWORK SERVICE, or an impersonated user.
    2. Check the Application Pool identity and profile behavior
      • In IIS Manager, open Application Pools.
      • Select the pool used by the Classic ASP site.
      • Open Advanced Settings.
      • Check Identity and Load User Profile.
      • loadUserProfile is false by default. If profile loading is involved, the temp location used by the process can change.
    3. Grant permissions to the correct temp location Based on the identity and profile behavior, make sure the failing identity has write access to the temp folder it is actually using:
      • %SystemDrive%\Windows\Temp
      • or %SystemDrive%\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp
      • or the Temporary ASP.NET Files location reported in the error
      For Jet/Access scenarios, the temp folder must allow the effective identity to create temporary files. For ASP.NET temporary folders, the process identity needs at least the required NTFS permissions; Microsoft guidance shows adding Modify access for the process identity on application content and temporary locations.
    4. If impersonation is enabled, test without it
      • If the site or related configuration is impersonating a user, the request may be running under that user instead of the app pool identity.
      • In ASP.NET scenarios, impersonation can be configured in Web.config with: 
             <identity impersonate="true" userName="<supplied username>" password="<supplied password>" />
      • If impersonation is in effect, the impersonated account must have NTFS permissions on the temp folder.
      • If possible, test with impersonation disabled so requests run consistently under the Application Pool identity.
    5. Use a safe troubleshooting test on the app pool identity
      • As a troubleshooting step only, temporarily change the IIS App Pool identity to a highly privileged account such as Local System.
      • If the site starts working, that confirms the root cause is missing NTFS permissions for the normal process identity.
      • Do not leave it configured that way as a solution.
    6. Check IIS logs and status codes
      • Review IIS logs for 401.x or 500 errors.
      • A 401.3 indicates unauthorized access due to ACLs on a resource, which is consistent with missing NTFS permissions.
      • If the browser only shows a generic 500 Internal Server Error, disable friendly HTTP errors and also check Event Viewer for more detail.
    7. If the error specifically references Temporary ASP.NET Files
      • Create or use a dedicated temp folder for the site if needed.
      • Grant only the site’s process identity Modify access to that folder.
      • This can help isolate the site from shared temp-folder permission issues.

    Since permissions were already granted to C:\Windows\Temp, the next likely issue is that the failing request is using a different identity or a different temp path than expected. The fastest way forward is to capture the exact ACCESS DENIED entry for w3wp.exe, then align NTFS permissions on that specific folder for that specific identity.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.