We are in the process of migrating an ASP Classic/ASP.NET application from IIS 6 to IIS 7.5. Most things run just fine in classic mode but we are having alot of problems with how errors are handled by IIS 7.5. We do our error reporting using a classic ASP page where we capture the error information here then redirect to a page to display the error. Based on our testing both Server.GetLastError and Request.ServerVariables("SCRIPT_NAME") when accessed from the logging page do not return the error details and source. Are there other ways we should retrieve the error information on IIS 7.5 or perform the logging?
In case this helps, using freb we have noticed that IIS appears to generate a completely new request then begins executing our error capturing.
Thanks in advance.
#smaclell: See http://dylanbeattie.blogspot.com/2008/12/fun-with-servergetlasterror-in-classic.html for a potential solution for you.
Here's the relevant paragraph from the article:
There was a very similar known bug in Vista which was supposedly fixed
in SP1, but it looks like the same fix isn't part of Windows 2008
Server yet. There is a workaround, though - if you set the site's
default error property (under IIS settings -> Error Pages -> Edit
Feature Settings...) to the custom page, IIS will invoke
this page whenever an error is not handled by an explicitly configured
status-code handler (so your 404, etc. handlers will still work) - but
for some reason, handling the error this way means
Server.GetLastError() still works properly.
Related
I'm migrating a ASP.NET application (3.0) from an old server (2003) to a new 2012 R2 server with iis 8. I copy the whole application and create a website. The first page loads fine but upon clicking any of the anchor tags which redirect the app to some other page, I get a "Thread was being aborted" error.
Any idea what could be causing this?
I seems to work fine on the old server, so I guess I'm missing out some iis setting.
PS: the issue has been solved.
The correct authentication mode was not enabled in IIS, and the code required the current user object, which was not available due to the same.
Hence, the issue.
Changing the auth-type from Anonymous to Windows solved the issue.
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
I have a dev and prod Windows 2008 R2 servers with IIS7 and siteminder, which as far as I can tell are setup the same. Issue being the production websites work but the development ones do not.
Issue being that when I navigate to any dev website, it says "the page cannot be displayed because an internal server error has occured." I do not get a challenge in dev (which I believe is the cause of the issue), but I do in prod. This goes for classic ASP pages or ASP.NET pages.
Some findings :-
- IIS has Windows authentication enabled and all others disabled
- Windows Authentication Provider is Negotiate (tried Negotiate:Kerberos, same result)
- WindowsAuthentication and WindowsAuthenticationModule (Native) are both present in Modules
- WindowsAuthentication is installed under Server Manager -> IIS -> Roles
- Upon receipt of the above error message, IIS logs shows the access with error 401 2 5
All the solutions I found online either do not have the right setup as I do above, or suggests I disable Windows authentication and enable Anonymous Authentication. If I do so, all works fine but the only issue being my websites require Windows authentication to identify the user. I'm at my wit's end and am just short of reinstalling something in hope it works. Any possibilities or log files that I have overlooked?
After screwing around a bit I finally solved my problem ... hope this helps someone.
I realized in fact ASP pages were working but ASP.NET pages were not working
When I had turned on Anonymous Authentication, the ASP.NET pages were now giving 500 0 or 500 19 errors in IIS logs, instead of 401 2 5 with Windows Authentication
I tried to launch a ASP.NET page from within the localhost and got then 500 error with a more detailed error saying I should use relative path in httpErrors under web.config (??)
At this point I realized I had earlier changed the 403 error to a custom file at the default website level, then changed it back. Despite changing it back to it's previous value, What this ended up doing was adding a "remove" then an "add" tag, both for 403.htm, under httpErrors in the wwwroot/web.config. After I deleted the entire httpErrors segment, my websites started working again.
Reverting back to Windows Authentication at this point also worked.
So some take aways is to test websites locally first and keep in mind the existing of the wwwroot/web.config giving near untraceable errors ...
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 ?
A vulnerability scanning service regularly tests our site for PCI scan compliance. It has just started trying to access URLs with abnormal formatting, such as:
http://www.mydomain.com/ShoppingCart.aspx//ErrorPage.aspx%3fid%3d2?
We have a Custom Error Page set which works for everything except this. Is there any way to force IIS to display it for this type of URL?
The Error: Runtime Error - An application error occurred on the server....
We're using:
ASP.NET 2.0 (Framework 3.5)
IIS 7.0 (Windows Server Web 2008)
I've tried to debug this, but I can't reproduce this on IIS 6.0.
There might be a more simple solution, but if you're on IIS7 you can use URL Rewrite to match those type of URLs and map them back to your error page.
The %3f part isn't being parsed by IIS 7 and so it can't find the page. If you look in your site logs you'll probably see some 404's.
You'll need to configure IIS 7 to point to your errorpage.aspx file as it's default 404 page.