IIS 8.5 long compilation and high memory peak on first access

I would uninstall and reinstall ASP.NET. I've had issues occur after installing the .NET Framework that I do this almost routinely now.

To uninstall:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ua

To reinstall:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i

If you need to run 32-bit applications, you would also need to run the aspnet_regiis in the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder. Note that performing the re-installation would affect other ASP.NET web applications if there are any running.

Because the issue occurs so early, it may be useful to enable the .NET Framework Fusion logging. This is designed to provide verbose information about what is occurring during the loading of assemblies.

If all the assemblies are loading ok, I would use Process Monitor to get a trace. That may point you in the right direction for what it was doing at the time of failure.

http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx

If it is an issue of a missing assembly, you can determine what assemblies your application needs by inspecting the manifest. This can be done with ildasm.exe (IL Disassembler) or ILSpy.

I've seen a lot of MVC apps crash at startup with a meaningless error message when introduced on a new server because an assembly (dll) existed in development or test, but not on the new server. If that is the case, it may be one of the following assemblies that need to be copied to the bin folder of the web site:

Microsoft.Web.Infrastructure.dll
System.Net.Http.dll
System.Net.Http.Formatting.dll
System.Net.Http.WebRequest.dll
System.Web.Extensions.dll
System.Web.Helpers.dll
System.Web.Http.dll
System.Web.Http.SelfHost.dll
System.Web.Http.WebHost.dll
System.Web.Mvc.dll
System.Web.Optimization.dll
System.Web.Providers.dll
System.Web.Razor.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll

When you install the ASP.NET MVC msi proper, it usually copies many of those files to a folder in C:\Program Files x86, or under C:\Windows\winsxs somewhere (global assembly cache).

Note that this issue may also occur if the vendor is signing their assemblies, but they are delay-signed. That would also be revealed in the Fusion log. A description of that symptom is here:

https://stackoverflow.com/questions/11030500/assembly-binding-error-bind-result-hr-0x80070002-the-system-cannot-find-the

Delay Signing an Assembly
http://msdn.microsoft.com/en-us/library/t07a3dye.aspx

This appears to be a duplicate of https://stackoverflow.com/questions/434272/iis7-overrides-customerrors-when-setting-response-statuscode , but I'm too new on Server Fault to flag this.

My take: I had a similar problem when using Mediawiki on an IIS server box.

When you browse to a non-existing page in Mediawiki. It sends back a special wiki page that says that the page doesn't exist and allows you to create it. However this page is sent with a status of 404.

On a standard IIS server IIS will automatically overwrite this with a custom error page to users NOT on the local host, but sends detailed error messages to those that are. In practice "detailed error messages" means letting through the original error page, whether it be custom in your application or generated by ASP.NET because of a coding error.

My method was to enable detailed error messages for both local and remote users in the Error Pages > Feature settings. However this will also allow remote users to see detailed ASP error messages should they occur, which may help a malicious user compromise your security.

Other options are given as answers to the linked question, including better ones that may not have a security implication. Another option in this case is to not return a 401 status code, but just a normal 200 code with your custom page. This sacrifices REST principles for ease of development.

Note that the fact that detailed error messages are shown for the local user, but not remote users, may explain why your solutions works during local testing but not when deployed.