Asp.net site wont run after windows update, Compilation error "Temporary ASP.NET Files"

Question

We ran windows update on one of our production machines. After this all of our asp.net applications stopped working and gave us the following error

System.Web.HttpCompileException (0x80004005): C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4a73fd31\133ab85b\App_Web_list.aspx.73bf660c.oobh7mac.0.vb : (0): error BC31007: Unable to open module file 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4a73fd31\133ab85b\App_Web_list.aspx.73bf660c.oobh7mac.0.vb': System Error &Hc0000005& (Visual Basic internal compiler error)
   at System.Web.Compilation.AssemblyBuilder.Compile()
   at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
   at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound)
   at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp)
   at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
   at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

After searching for a few minutes i found a solution changing the user the apppool runs under from ApplicationPoolIdentity to LocalSystem.

This solved the problem but i do not feel conformable with our application running as LocalSystem.

I have tried to compare security on the "Temporary ASP.NET Files" and "Temporary ASP.NET Files\root" with a healthy machine without being able to find any differences.

Does any one know what to do to solve this problem?

Edit: This problem happens when we try to visit the page not when we try to compile it!

Answer 1

I found a solution, i gave the IIS_USERS full access to C:\Windows\Temp.

Answer 2

Also started to have same problems yesterday with site on Windows Server 2003, which used to work fine during years under NETWORK SERVICE account.
NETWORK SERVICE (in your case ApplicationPoolIdentity) has full control permissions to C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

These are the steps to resolve this problem:

1. .Net framework could be broken on your server after installing updates.
   Try to repair .Net Framework4.0 with "Microsoft
   .NET Framework Repair Tool" http://www.microsoft.com/en-us/download/details.aspx?id=30135. .NET Framework Repair Tool will diagnose and repair .NET Framework 4 issues
2. Recycle application pool. Delete all compiled libraries from C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files This will push compiler to re-compile all code which it compiles on fly, just in case if there were some corrupted or locked by some other processes assemblies.

Answer 3

I had a similar situation that I spent quite a few hours trying to solve. In my case I am running on a windows 2008R2 box. I tried messing with the temp file security, re-installing .net4 framework, rebooting etc to no avail.

The final steps I went through was to create a brand new app pool - using the identical settings as the old one, then set the website to use the new app pool, and finally delete the old app pool.

All I can speculate is that something about the order in which IIS, .net3, .net4 and the various windows updates cause the app pool to be "corrupt" in some way. Hopefully this nugget will prove helpful to someone.