The Problem

I have a website running in IIS. If I rename or delete one of the layout page .cshtml files under /Views/ the site immediately begins throwing following yellow screen error as expected

The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".

What surprises me is that if I recreate or rename the file so it is exactly like it was before, the yellow screen persists. Why is this particular 500 error sticky?

I currently think that this has something to do with IIS and is specifically related to error handling. The site immediately detects that the layout page file is missing. It does not immediately realize when the file is back in place.

Thanks!

Some interesting clues

1. This happens on all of my sites I've tried this on so far. It isn't related to a specific site
2. I tried this on two websites at the same time. On one site I repeatedly and consistently refreshed the page hoping for a success. On the other, I left it alone for several minutes before checking again. The site I leave alone will resolve its problems and find the layout page on disk again. The site I continually make requests to appears to display the error indefinitely.

What I've tried

1. I have reproduced the problem on Umbraco websites using Umbraco's default routing as well as regular MVC pages using custom routing. The problem is the same for both.
2. I don't have output caching configured in IIS
3. When I am reproducing the yellow screen error, I am able to reproduce the error in multiple browsers, so I don't believe it is related to browser caching
4. I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
5. I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
6. I am able to reproduce the problem on websites where there is no custom code for caching. No CDN. No load balancer.

Versions

• IIS: I have reproduced the problem on Windows Server 2012R2 running IIS 8 and Windows 11 running IIS 10
• CMS: All of the websites I have tested on so far are Umbraco 7 sites. However, I have reproduced the problem on pages that are routed using Umbraco's out of the box routing as well as pages that are just set up using MVC and aren't leveraging Umbraco.

CodePudding user response：

It appears to be part of the behavior of FcnMode="Single". See https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-4.8. It isn't an issue with caching. It is a problem with the way that the site's file change notifications (FCN) are configured.

The sticky 500 behavior on renaming files happens when I use FcnMode="Single" but not when I use FcnMode="Default".

FcnMode="Single" will result in only a single object to monitor file changes. This single object is responsible for monitoring changes to files in the main directory and sub directories.

FcnMode="Default" will result in a separate object to monitor file changes for each directory.

Umbraco sites, by default, use FcnMode="Single". This makes sense because Umbraco sites cache under very deeply nested directories in /App_Data/. This can result in so many of these monitors that it can affect the performance of the site. There is a great explanation of FcnMode and why it matters for Umbraco here: https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/

Unfortunately, it appears that the single file monitor can miss renames of files in some cases.