I have written an ASP.NET MVC App that is running on a Google Compute Engine. The app is getting a 500 Error on the main Index page that does not occur when running on my local machine.
I am trying to get the complex error page to show from the server, as it is much easier to view them on the web page for hotfixing issues than to delve into the Google Cloud Console to retrieve them. I do not want custom errors, just the same amount of depth that gets shown when running on my local machine.
I have tried:
Removing the existing HTTP Global Filter
Adding <customErrors
mode="Off"/><compilation debug="true"/> to my System.Web in
Web.config
Adding <httpErrors errorMode="Detailed" /><asp
scriptErrorSentToBrowser="true"/> to my System.WebServer in
Web.config
Publishing as debug
Ideas? I'm sure theres a publish setting I'm missing somewhere.
Adding a constructor to the page controller finally provided the detailed error log. If you have taken all of the steps above to get the log, and it still has yet to show, ensure there are constructors for all view controllers involved. Even if the constructor is blank.
I still need to delve into my particular crash issue, but at least I can get an idea where to start.
Related
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
This happens on all of my sites I've tried this on so far. It isn't related to a specific site
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
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.
I don't have output caching configured in IIS
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
I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
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.
It appears to be part of the behavior of FcnMode="Single". See https://learn.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.
Im trying to upload a MVC site to a server but it just seems it wont play ball. Never had such weird errors for uploading a mvc site.
Get this message when I navigate to the web page.
The attribute 'debug' has been locked in a higher level configuration.
What the h... does that mean?
Source error:
An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
some part of the web.config that I have been messing around with:
<customErrors mode="Off">
</customErrors>
<compilation debug="false" />
It means that the debug attribute has been set at machine level and you are not allowed to change it. This is done in the global IIS configuration file that you won't have access to. In effect, a web.config just inherits from that and all your XML is just overriding or adding to those values.
Now I assume it's been locked to prevent debug="true", this means you can just remove that attribute completely, which means you can remove the entire compilation element.
I made glimpse defaultRuntimePolicy Off but it still shows an error like this
Unable to define EFProfiledDbProviderServices class of type 'GlimpseDbProviderServices'. Please check that your web.config defines a <DbProviderFactories> section underneath <system.data>
shouldn't glimpse be out of asp.net mvc pipeline after making it off?
Update :
I also commented all the glimpse related part in web.config but I still get the same above error
The reason is that even when you disable Glimpse completely through the web.config, which makes sure Glimpse is not collecting any information during request processing, that there are still assemblies, like Glimpse.Ado and Glimpse.EF*, that have a PreApplicationStartMethod attribute defined, which means that some hooks are being put in place, even though they are not going to do anything when requests are being processed.
The solution is to remove the Glimpse.EF* assembly, and maybe the Glimpse.Ado assembly as well, from you bin directory.
I try to deploy ASP MVC 5 app in virtual directory (without creating new iis application)
I use IIS 7.5
I already put
<modules runAllManagedModulesForAllRequests="true"/>
<directoryBrowse enabled="true" />
in web.config file.
But when i go to app url with IE browser it shows me just directory listing like in screenshot below
Is there a way to deploy MVC 5 in virtual directory and make it work like usual MVC application?
You need to convert the virtual directory to application. Right click on it in the IIS management console and choose Convert To Application.... Also make sure that the associated application is configured to use Integrated Pipeline Mode.
I solved this problem earlier in my production environment by checking the directory pointer in IIS. Apparently when I unzipped the deployed site from one server to the next, the zip utility made an extra level, so IIS was pointing to /MyProject when the files were in /MyProject/MyProject. I had a little better clue though, you have Document Browsing enabled based on that screen shot, make sure not to do that in production. I set the site to log custom errors and got a 403.14 response, from there found a blog on my mistake. You need to setup the environment to find the specific module that's failing, I think something to do with trace routes, idk. I'm a software developer that always gets forced into doing devOps; was googling my own problem and thought I'd throw you a line. Without a specific error message, all I can tell you is IIS is not connecting to .NET; something is not configured correctly. Turn off directory browsing, google how to get good error logs back, and let us know the status code so we can help you: 403.14, 401, 500, 404? Also give us the module that's failing. If it's the last one on the handler list, guess what, IIS isn't connecting to the app, which I suspect is your case.
I was wondering why could I have not caught this issue in local testing? I am using a Content Panel user control in all my user controls. In one of the user control I missed the register tag for Content Panel UC. While testing locally all things were working fine . Suddenly on our QA box I got a critical issue. Application was throwing Unknown server tag 'cc1:ContentPanel' in the Landing page.
Can anyone explain why it was not caught locally?
Most likely there is a mismatch in your web.config files.
Use a diff program to compare the web.config on QA against the web.config on your box.
I bet you'll find the problem there...