IIS 500 error on postback or upload on some computers - asp.net

I run a website on IIS 8.5 and ASP.NET. I recently moved my website to a new server. Some users are getting an internal server error when trying to postback or upload on the site. As an example, when they try to reply in the forum (I use YetAnotherForum), they will get the error page.
I think I've narrowed it down to postbacks. Whenever there is a postback, they will get the error. This includes using ASP.NET buttons on the page.
My big problem is that the error is not logged anywhere. It is not in the event viewer, failed request logs, or even the server log. I have all application errors caught and logged in Global.asax, but the error never reaches the handler. The users just get the error on the screen and it doesn't seem to be recognized at all by the server. Here is a screenshot of the error:
Generic IIS Error
As you can see, it is a very generic IIS error.
I am still maintaining a test site on my old server. I sent one person that was getting the error to the test site to see if he got the error. He did not - he only gets the error on the new site on the new server. I'm guessing it must be some setting I am missing.
Only a select few users are getting the error. The ones I have talked to are using Windows 10. They have tried all of the different browsers (IE, Firefox, and Chrome), and none of them work. I also have Windows 10, but I do not get the error.
Any chance someone has seen this error and knows the fix?

Related

Blazor webassembly with authorization fails with failed to fetch on blazor.boot.json

I added authorization to an asp.net hosted web assembly app. When starting the app it correctly starts to redirects to the login page but then only shows a white screen. In the javascript console I see error "failed to fetch" for blazor.boot.json. Firefox reports this as NS_BINDING_ABRORTED. Strangely running this in chrome reports the same javascript error but fiddler reports a 304. Worst is that this was working in the past and stopped working. I moved back many commits in the git repository of my project and none works, so it was not a recent change. I installed the code on a new machine and get same error there.
See attached screenshots:
There are two parts to my answer:
1.) The failed to fetch error still exists and I think it is a blazor bug as the authorization redirects so I think started request just get cancelled and this is not caught.
2.) The reason why I had a white screen was similar. CSS hides everything until my code sets it and it was a race condition if this was not finished before the redirect triggers, it never set the display value.
So posting this here if people get the "failed to fetch" error, that it seems to do no harm.

Custom Error mode set to "RemoteOnly", debugging locally still shows custom error page

In two of our ASP.Net Web Applications, in the Web.Config file, we've set the Custom Error redirect to our custom error page, and set the mode to "RemoteOnly" so that when we debug locally we see any unhandled exception message displayed on the "Yellow Screen of Death" - "YSoD".
This week, we discovered that when an unhandled exception is encountered, all of a sudden we're getting our custom error pages, instead of the exception details in the "YSoD".
This applies to only two, of the several applications we're running. I've searched high and low for a similar problem/solution, and haven't found much.
I'm trying to determine if this is an Application, IIS, or Visual Studio configuration problem. It just started happening, and there were no significant changes made to the server, etc., to potentially explain the problem. We have enabled IIS Failed Request Tracing, but I couldn't find anything associating this with our problem.
Given this information, what can cause this sudden change in behavior?
The back-end is a SQL Server database, using Windows Authentication, on an AWS VPC.

Why are blank pages being served with "200 OK" for asp.net errors in IIS 8.5 (Win 2012 R2)?

I've set up a new Windows 2012 R2 server running IIS 8.5.
We noticed that when an error occurs (eg the ASP.NET State Service was not running) that instead of outputting a 500 status code error screen, the request actually returns a totally blank page (only headers - with no content). We obviously need to see the errors and serving 200 OK for an error could be very problematic for indexers like Google etc or any wesite monitoring tools (which would not notify us that the site had gone offline).
On our other servers (IIS 7) we see the "yellow error screen" with a message like "could not connect to state server" (or similar).
What could possibly be wrong here? Is there some setting to globablly disable all errors (but this would be stupid if it also serves the 200 status code) or could something else be getting in the way?
The only other thing which could be interfering is we've got ISAPI_Rewrite installed on the server (but this doesn't usually cause this problem).
Thanks!
Had a similar issue on Windows 8.
In settings search for "Turn Windows features on or off".
Check that the following features are enabled
"/Internet Information Services/World Wide Web Services/Common HTTP Features/HTTP Errors".
"/Internet Information Services/World Wide Web Services/Common HTTP Features/Static Content".
You need to ensure Server Side Debugging is not enabled in the ASP module.
Classic ASP server 500 errors are returned as 200's. An attempt is made at opening the Server Side Debug Application, that then can't be found and IIS subsequently returns a 200 response and a blank page.
Make sure that you are not calling Server.ClearError() in Application_Error of Global.asax.cs that ended up being my problem.
Ripping out all Global.asax code helped me to find the cause of the error.
After that, the IIS started to return the error page as expected. Then, after the fix is applied, I returned the Global.asax code back.
Maybe this case helps you.
I had a similar issue when requesting the Default.aspx (set as page default in directory). The Server returned status 200, but the Content was blank.
In this case it worked to switch the Application pool's managed pipeline mode from integrated to classic.
Make sure you have enabled HTTP Activation

ASP will not run unless logged into console

I am moving an existing ASP application from IIS5 on Win2003 to IIS7 on Win2008.
After going over all the install notes and setting up ASP to run, everything worked fine while I was logged into the console.
As soon as I log off the console, no ASP application will run. I get a 500 error even though normal .htm pages will render from the site fine.
I tried a simple page with only a response.write " Hell " and it fails with a 500 error. I set up Failed Request error logging and it just says 500 error as soon as it calls the ASP script.
How can this be solved?
Solution
Tweaked a setting in IIS:
Internet Information Services (IIS) Manager ->
Default Web Site ->
Error Pages properties
select Detail errors
Reset to Detailed errors only and now everything works
Out of the blue Google Search:
Classic ASP on IIS7: refusing to send errors to browser on 500 Internal Server Error
Does this help you ?

I'm getting blank pages instead of error messages using classic ASP, IIS6 and WinServer 2003 R2

We have an old system running on a WinServer2003 R2 - IIS6 and it was written using classic ASP.
We need to trap all errors and for that, I configured IIS to redirect 404s and 500s to a custom page (custom errors config) that writes the info to a log file (this page creates and manages the logs).
Here is the weird thing: The first time the error occurs, the page is redirected and I get my log file entry. But, if this page is loaded again (I hit F5, or other user goes there, etc), the browser receives a blank page: no error message and my custom page is ever called.
If I restart IIS6 I get the same behavior, first time it works, next not.
-> Send ASP errors to browser is turned on
-> Show friendly http errors is turned off in my explorer
Any thoughts?
You need to ensure Server Side Debugging is not enabled in the ASP module.
Classic ASP server 500 errors are returned as 200's. An attempt is made at opening the Server Side Debug Application, that then can't be found and IIS subsequently returns a 200 response.
Try doing this while running Fiddler ( http://www.fiddlertool.com/Fiddler2/version.asp ) or some other tool that makes it possible to see what's being sent here and there.
Also; if you set IIS to log in the IIS log format, errors will show up in the log file at the very end of the line for the request that ended in error.
maybe its this issue
http://www.webdevbros.net/2006/11/26/ie7-bug-blank-page-white-screen-after-some-refreshs/

Resources