Jump to content

Recommended Posts

Posted

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.


servererror.png

 

Regards

Click Studios

  • 7 months later...
Posted

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?

Thanks

Click Studios

  • 4 months later...
Posted

Hi,

I have just upgraded and got this error hence why I'm here.

 

I have rebooted the server but it didn't clear. i have then set the CustomErrors to off and now get the below. Any help would be appreciated.

 

 

 

Capture.JPG

Posted

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.

Regards

Click Studios

  • 1 year later...
Posted

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.

Posted

Fantastic feedback Goossens, we really appreciate you documenting this here.  Hopefully this helps out other customers with the same issue.

 

Regards,

Support

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