Jump to content

Server Error in '/' Application after Upgrade


Recommended Posts

We’ve had a couple of reports of the error screen below after upgrading Passwordstate, and we believe this is a transient IIS caching issue.


To fix this, simply restart each of the Passwordstate Application Pools in IIS, or reboot your server,  and this will fix it. We will continue to investigate if we can reproduce this consistently, so we can work on a fix.




Click Studios

Link to comment
Share on other sites

  • 7 months later...

Hi Lennart,


No sorry there has not been, as we've never seen the issue ourselves - we need to replicate an issue in order to fix it.


And we believe it's some sort of IIS caching issue, and a reboot of the web server normally fixes it - so it's not a code thing we are able to provide a fix for.

Are you still seeing this after a reboot? If so, can you please edit the file c:\inetpub\passwordstate\web.config file, and turn CustomErrors off. When you save the file and access the site again, does it report the error?


Is your screen reporting this generalerror.aspx, or customerror.aspx?


Click Studios

Link to comment
Share on other sites

  • 4 months later...

Hello Garry,


We believe this issue is caused by you not following the upgrade instructions correctly - you are first meant to upgrade to build 8995, and then you can upgrade to version 9.


Can you please restore your system, and as of next Monday, we are releasing build 9300, with a lot easier upgrade process.

Thanks very much.


Click Studios

Link to comment
Share on other sites

  • 1 year later...

On our PasswordState server (V9, several build nrs), this intermittent error occurred several times, with weeks and even months in between. In the end, we found that it was caused by a bug in .NET version 4.7.


When the issue occurs, the event log has warnings containing the following:

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Level:         Warning
Exception information:
    Exception type: HttpException
    Exception message: The file '/Default.aspx' has not been pre-compiled, and cannot be requested.


Further symptoms:

  • Restarting the website or rebooting the server does not solve the issue.
  • Restoring a recent backup of the VM solves the problem.


The following references led me to the bug in .NET 4.7:

  1. https://techcommunity.microsoft.com/t5/iis-support-blog/the-file-has-not-been-pre-compiled-error-and-solution/ba-p/945340
    • This intermittent error may show up in Event Viewer when your application fails to load: “The file has not been pre-compiled, and cannot be requested”. The intermittent nature of the issue makes it difficult to troubleshoot it but there are a couple of possible root causes and solutions.
    • There is a known bug in .NET Framework 4.7.x that causes this issue
  2. https://stackoverflow.com/questions/55272598/sporadic-error-the-file-has-not-been-pre-compiled-and-cannot-be-requested
    • According to Microsoft this is caused by a known bug with the .Net Framework versions 4.7.x triggered by memory pressure in the web server worker process.
    • When [this specific issue] occurs, the .Net Framework creates a .delete file next to the assembly to mark it as stale.
    • This will prevent the worker process from loading the file back into memory cache and causes the compilation error you are seeing.
  3. https://github.com/microsoft/dotnet/blob/main/releases/net48/dotnet48-changes.md
    • .NET Framework 4.8 Release Notes
    • Fixed an issue introduced in ASP.NET 4.7, where the unexpected removal of a particular type of cache item can result in an orphaned *.delete file that prevents web applications from running. [750653, System.Web.dll, Bug, Build:3734]


I found one *.delete file in the "Temporary ASP.NET Files" folder, named "PasswordstateResources.dll.delete". Its timestamp matched the time of the first event log warning (and the time users started reporting issues). Deleting this *.delete file solves the problem.


The real solution, in this case, is to upgrade to .NET 4.8.


The stackoverflow article referenced above has several suggestions for a workaround while using .NET 4.7. We chose to temporarily set the private memory recycling conditions on the application pool in IIS, until we are ready to upgrade .NET.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...