CustomErrors mode="Off"

This has been driving me insane for the past few days and couldn't get around it but have finally figured it out:

In my machine.config file I had an entry under <system.web>:

<deployment retail="true" />

This seems to override any other customError settings that you have specified in a web.config file, so setting the above entry to:

<deployment retail="false" />

now means that I can once again see the detailed error messages that I need to.

The machine.config is located at

32-bit

%windir%\Microsoft.NET\Framework\[version]\config\machine.config

64-bit

%windir%\Microsoft.NET\Framework64\[version]\config\machine.config 

Hope that helps someone out there and saves a few hours of hair-pulling.

"Off" is case-sensitive.

Check if the "O" is in uppercase in your web.config file, I've suffered that a few times (as simple as it sounds)

In the interests of adding more situations to this question (because this is where I looked because I was having the exact same problem), here's my answer:

In my case, I cut/pasted the text from the generic error saying in effect if you want to see what's wrong, put

<system.web>
   <customErrors mode="Off"/>
</system.web>

So this should have fixed it, but of course not! My problem was that there was a <system.web> node several lines above (before a compilation and authentication node), and a closing tag </system.web> a few lines below that. Once I corrected this, OK, problem solved. What I should have done is copy/pasted only this line:

<customErrors mode="Off"/>

This is from the annals of Stupid Things I Keep Doing Over and Over Again, in the chapter entitled "Copy and Paste Your Way to Destruction".

You can generally find more information regarding the error in the Event Viewer, if you have access to it. Your provider may also have prevented custom errors from being displayed at all, by either overriding it in their machine.config, or setting the retail attribute to true (http://msdn.microsoft.com/en-us/library/ms228298(VS.80).aspx).

I tried most of the stuff described here. I was using VWD and the default web.config file contained:

    <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
        <error statusCode="403" redirect="NoAccess.htm" />
        <error statusCode="404" redirect="FileNotFound.htm" />
    </customErrors>

I changed mode="RemoteOnly" to mode="Off". Still no joy. I then used IIS manager, properties, ASP.Net Tab, Edit configuration, then chose the CustomeErrors tab. This still showed RemoteOnly. I changed this to Off and finally I could see the detailed error messages.

When I inspected the web.config I saw that there were two CustomErrors nodes in the system.web; and I have just noticed that the second entry (the one I was changing was inside a comment). So try not to use notepad to inspect web.config on a remote server.

However, if you use the IIS edit configuration stuff it will complain about errors in the web.config. Then you can rule out all of the answers that say "is there an XML syntax error in your web.config"

If you're still getting that page, it's likely that it's blowing up before getting past the Web.Config

Make sure that ASP.Net has permissions it needs to things like the .Net Framework folders, the IIS Metabase, etc. Do you have any way of checking that ASP.Net is installed correctly and associated in IIS correctly?

Edit: After Greg's comment it occured to me I assumed that what you posted was your entire very minimal web.config, is there more to it? If so can you post the entire web.config?

I also had this problem, but when using Apache and mod_mono. For anyone else in that situation, you need to restart Apache after changing web.config to force the new version to be read.

We had this issue and it was due to the IIS user not having access to the machine config on the web server.

Try restarting the application (creating an app_offline.htm than deleting it will do) and if you still get the same error message, make sure you've only declared customErrors once in the web.config, or anything like that. Errors in the web.config can have some weird impact on the application.

Do you have any special character like æøå in your web.config? If so make sure that the encoding is set to utf-8.

Is this web app set below any other apps in a website's directory tree? Check any parent web.config files for other settings, if any. Also, make your your directory is set as an application directory in IIS.

If you're using the MVC preview 4, you could be experiencing this because you're using the HandleErrorAttribute. The behavior changed in 5 so that it doesn't handle exceptions if you turn off custom errors.

You can also try bringing up the website in a browser on the server machine. I don't do a lot of ASP.NET development, but I remember the custom errors thing has a setting for only displaying full error text on the server, as a security measure.

Having tried all the answers here, it turned out that my Application_Error method had this:

Server.ClearError();
Response.Redirect("/Home/Error");

Removing these lines and setting fixed the problem. (The client still got redirected to the error page with customErrors="On").

That's really strange. I got this error and after rebooting of my server it disappeared.

For me it was an error higher up in the web.config above the system.web.

the file blah didn't exist so it was throwing an error at that point. Because it hadn't yet got to the System.Web section yet it was using the server default setting for CUstomErrors (On)

None of those above solutions work for me. my case is

i have this in my web.config

<log4net debug="true">

either remove all those or go and read errors logs in your application folder\logs eg.. C:\Users\YourName\source\repos\YourProjectFolder\logs

It may not be IIS!

I went through all of the answers on this page, as well as several more. None of them solved our issue, BUT they are good things to check and WILL cause problems. SO check those first. If you're still pulling your hair out, and you're using PHP, check your PHP settings.

What fixed it for me was to edit our php.ini file and specify:

display_errors: On

I also set:

display_startup_errors: On

just for good measure.

That fixed the problem, and our real issue turned out to be a missed comma that was missed during dev to stage migration.

I realize this page was linked to asp.net, which we were ALSO using, and this is not an asp.net issue, but when you search for these errors, this page comes up and has some good info for fixing most common problems; just not our specific issue. The config changes did fix it, and then we could concentrate on our asp.net files!