IIS 7.5 , 2008rc2, classic asp, 500 error msg:
The page cannot be displayed because an internal server error has occurred.
I need to know how to configure IIS to get a more detailed error.
I've tried setting to true all of debugging options in the ASP configuration.
But that didn't work. Can anyone help me?
I have come to the same problem and fixed the same way as Alex K.
So if "Send Errors To Browser" is not working set also this:
Error Pages -> 500 -> Edit Feature Settings -> "Detailed Errors"
Also note that if the content of the error page sent back is quite short and you're using IE, IE will happily ignore the useful content sent back by the server and show you its own generic error page instead. You can turn this off in IE's options, or use a different browser.
If you're on a remote server you can configure your web.config file like so:
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
<asp scriptErrorSentToBrowser="true"/>
</system.webServer>
<system.web>
<customErrors mode="Off"/>
<compilation debug="true"/>
</system.web>
Double click "ASP" in the site's Home screen in IIS admin, expand "Debugging Properties", enable "Send errors to browser", and click "Apply".
Under "Error Pages" on the home screen select "500", then "Edit feature settings" and select "Detailed Errors".
Note that the same steps apply for IIS 8.0 (Windows Server 2012).
After trying Vaclav's and Alex's answer, I still had to disable "Show friendly HTTP error messages" in IE
TLDR:First determine where in the pipeline you're getting the error from (scroll looking for screenshots of something that resembles your error), make changes to get something new, repeat.
First determine what error message you are actually seeing.
If you are seeing the file located here...
%SystemDrive%\inetpub\custerr<LANGUAGE-TAG>\500.htm
...which generally looks like this:
**...then you know you are seeing the currently configured error page in IIS ** and you do NOT need to change the ASP.net customErrors setting, asp error detail setting, or "show friendly http errors" browser setting.
You may want to look at the above referenced path instead of trusting my screenshot just in case somebody changed it.
"Yes, I see the above described error..."
In this case, you are seeing the setting of <httpErrors> or in IIS Manager it's Error Pages --> Edit Feature Settings. The default for this is errorMode=DetailedLocalOnly at the server node level (as opposed to the site level) which means that while you will see this configured error page while remote, you should be able to log on locally to the server and see the full error which should look something like this:
You should have everything that you need at that point to fix the current error.
"But I don't see the detailed error even browsing on the server"
That leaves a couple of possibilities.
The browser you are using on the server is configured to use a proxy
in its connection settings so it is not being seen as "local".
You're not actually browsing to the site you think you are browsing to - this commonly happens when there's a load balancer involved. Do a ping check to see if dns gives you an IP on the server or somewhere else.
Your site's httpErrors settings is set for "Custom" only. Change it to "DetailedLocalOnly". However, if you have a configuration error, this may not work since the site level httpErrors is also a configuration item. In that case proceed to #4
The default for httpErrors for all sites is set for "Custom". In this case you need to click on the top level server node in IIS Manager (and not a particular site) and change the httpErrors settings there to DetailedLocalOnly. If this is an internal server and you're not worried about divulging sensitive information, you could also set it to "Detailed" which will allow you to see the error from clients other than the server.
You're missing a module on the server like UrlRewrite (this one bites me a lot, and it often gives the generic message regardless of the httpErrors settings).
"Logging on to the server is not an option for me"
Change your site's httpErrors to "Detailed" so you can see it remotely. But if it doesn't work your error might already be a config error, see #3 immediately above. So you might be stuck with #4 or #5 and you're going to need somebody from your server team.
"I'm not seeing the error page described above. I'm seeing something different"
If you see this...
...and you expect to see something like this...
...then you need to change "Send errors to browser" to true in IIS Manager, under Site --> IIS --> ASP --> Debugging Properties
If you see this...
or this...
...you need to disable friendly errors in your browser or use fiddler's webview to look at the actual response vs what your browser chooses to show you.
If you see this...
...then custom errors is working but you don't have a custom error page (of course at this point were talking about .net and not classic asp). You need to change your customErrors tag in your web.config to RemoteOnly to view on the server, or Off to view remotely.
If you see something that is styled like your site, then custom errors is likely On or RemoteOnly and it's displaying the custom page (Views->Shared->Error.cshtml in MVC for example). That said, it is unlikely but possible that somebody changed the pages in IIS for httpErrors so see the first section on that.
In web.config under
<system.webServer>
replace (or add) the line
<httpErrors errorMode="Detailed"></httpErrors>
with
<httpErrors existingResponse="PassThrough" errorMode="Detailed"></httpErrors>
This is because by default IIS7 intercepts HTTP status codes such as 4xx and 5xx generated by applications further up the pipeline.
Next, enable "Send Errors to Browser" under the "ASP" section, and under "Error Pages / Edit Feature Settings", select "Detailed errors".
Also, give Write permissions on the website folder to the IIS_IUSRS builtin group.
try setting the value of the "existingResponse" httpErrors attribute to "PassThrough". Mine was set at "Replace" which was causing the YSOD not to display.
<httpErrors errorMode="Detailed" existingResponse="PassThrough">
One thing nobody's mentioned is as a very quick and temporary fix, you can view the error on the localhost of that web server.
You may also verify that if you changed your main website folder (c:\inetpub\wwwroot) to another folder you must give read permission to the IIS_IUSRS group in the new folder.
Fot people who have tried EVERYTHING and just CANNOT get the error details to show, like me, it's a good idea to check the different levels of configuration. I have a config file on Website level and on Application level (inside the website) check both. Also, as it turned out, I had Detailed Errors disabled on the highest node in IIS (just underneath Start Page, it has the name that is the same as the webservers computername). Check the Error Pages there.
Found it.
http://blogs.iis.net/ksingla/archive/2009/02/16/iis-7-5-updates-to-custom-errors-and-compression.aspx
run cmd as administrator, go to your system32\inetsrv folder and execute:
appcmd.exe set config -section:system.webServer/httpErrors -allowAbsolutePathsWhenDelegated:true
Now I can see detailed asp errors .
If you run the browser in the server and test your url of the project with the local ip you have received all errors of that project without a generally error page(for example 500 error page).
In my case it was permission issue.
Open application folder properties -> Security tab -> Edit -> Add
IIS AppPool\[DefaultAppPool or any other apppool] (if use ApplicationPoolIdentity option)
IUSRS
IIS_IUSRS
Double check the encoding of the asp file you are testing.
For instance if you created a file like below on a Windows Server Core 2019 :
echo "<%# LANGUAGE=Javascript %>" > test.asp
echo "<%Response.Write("test");%>" >> test.asp
Then test.asp will be encoded in Unicode, and requesting it will produce a 500 without any details.
Do a notepad test.asp, then click on "Save As..." and choose "ANSI" encoding to fix it.
I got an issue when using HttpContext.RewritePath in HttpModule for URL rewriting.
Environment: Windows Server 2008 R2, IIS 7.5 integrated mode, .Net 4.0
In my project, most URLs will be rewritten to the same aspx page(Handler.aspx). The aspx page will do different thing based on the URL.
Example:
"/en/abc/" will be written to Handler.aspx. [Page output: This is abc]
"/en/test/" will be written to Handler.aspx. [Page output: This is test]
"/en/test/a.html" will be written to Handler.aspx as well. [Page output: This is test]. As I only check the string "test" and ignore the sting "/a.html", the output is same as the URL "/en/test/". And a.html doesn't exist in wwwroot folder, the URL is a bad case for testing.
I got a issue, if 2 or more requests that contain htm/html extension come simultaneously
Example: "/en/test/a.htm" or "/en/test/a.html"
HttpContext.RewritePath will not work for any request after that. Handler.aspx won't be called any more, and the page output will always be 'This is test' no matter what URL entered. Http status code is 200 when the issue occurs. Also if visit the real aspx page(Handler.aspx), it will display the same content 'This is test' as well. It seems like a server-side cache. And this issue can be resolved by recycling app pool in IIS.
In following cases, the issue won't occur:
Visit these two requests with a delay, for example visit "/en/test/a.html" first and wait 3-5 seconds, then visit "en/test/a.html" again. Everything works fine.
Change IIS pipeline from integrated mode to classic mode. If visit "/en/test/a.html", a IIS 404 page will be displayed.
Use Server.Transfer instead of HttpContext.RewritePath, everything works fine.
The URL contains .php, .jsp, .xml won't cause the issue
I have to find the root cause of it. Any potential reason may cause this issue?
Where can i find the default htm file, mapped to show the 404 error in Sharepoint service 2.0. Currently whenever the request for a site hits the 404 error, it goes to the default page, but the point to note here is, which is not the one we set in IIS custom error option.
My requirement here is to make few modification in the 404 error page. I tried mapping the request to a custom error page with <customErros> tag in web.config. But unfortunately, its still showing the default 404 error page. When i checked the viewsource of the error page i can see some comments like, res://shdocvw.dll/http_404.htm#http://www.DocURL.com/bar.htm
Any idea about this? Thanks in advance
I haven't had to do this but this entry looks quite reasonable: http://blogs.msdn.com/b/jingmeili/archive/2007/04/08/how-to-create-your-own-custom-404-error-page-and-handle-redirect-in-sharepoint-2007-moss.aspx
Basically when you install WSS it hi-jacks IIS. You can still do most of the things you would expect but you need to go through the Central Administration pages and the XML files that control many aspects of SharePoint.
I have a custom error page. It works on my production server, but not on my dev machine. It's Windows 7, IIS 7.5.
I cannot get it to actually execute my custom page, although I can get it to respect detailed-local vs custom always. It just doesn't actually hand over to my custom error page and instead gives me the generic "Runtime Error" page for the remote mode.
Facts that might be relevant: it's an application mounted under a different app pool and web.config, this one is .NET 4.0, Integrated.
I was able to get it working, once, with "Response.TrySkipIisCustomErrors = true;" - but it did a redirect instead of an execute so I lost the error context which of course is the whole point - and in trying to change the redirect mode I was unable to get it to work again.
I've tried using both customErrors and httpErrors in all the documented/standard ways, but no combination works. Again, I have had this working correctly elsewhere.
The above is a normal response - if your error page is itself generating an exception.
It turned out the same code causing the original error was in the execution of the error page.
I'm trying to return a custom 404 page using IIS6. (I have a site that is mostly .shtml pages built using movable type). I have tried it 2 ways:
1) set the 404 error handler in IIS to be type "file" with the path \404.html. This works, but it also means that I can't import the header and footer of my site (hence the .shtml) Trying to point the 404 error handler to 404.shtml results in the default 404 page...i guess IIS can't process shtml files in the 404.
2) set the type to "URL". This works great, except that the response code is no longer 404! Its a 200.
How can I get IIS to respond with a 404 response code with the content of my 404.shtml file?
Given that it's IIS, adding
<% Response.Status = "404 Not Found" %>
to the top of 404.shtml should change the response code to 404.
I am not on a windows machine so I am unable to test it at the moment to verify.
Update:
I was finally able to run a few tests on a IIS 6. As you mentioned in a comment to my post, an .shtml file does not allow script commands to run. So there are at least two ways to work around this:
Instead of naming your custom 404 handling page 404.shtml, name it 404.asp. The user should never see the actual name of the page so it shouldn't cause any issues. Note that "Active Server Pages" must be set to 'Allowed' in the Web Service Extensions folder of IIS.
Modify the page extension mapping for .shtml to use asp.dll instead of ssinc.dll. You can do this from IIS by selecting the website and viewing Properties -> Home Directory tab -> Configuration -> Mappings tab. Note that this is far from an ideal solution because now all your .shtml files will be processed by asp.dll. This could cause your pages to render more slowly (assuming asp.dll processes files more slowly than ssinc.dll due to greater complexity) and violates the principle of least privilege.
If neither of the options fit your situation, then it may still be possible but the solution isn't immediately obvious to me.
In IIS Manager, open the Properties of your Web site (or virtual dir) and go to the Custom Errors tab. There you can set which file is sent in case of each error code, including 404.