CustomErrors mode = «Off»

"Выкл." чувствителен к регистру.

Проверьте, что "O" находится в верхнем регистре в файле web.config, я несколько раз потерпел (как это просто звучит)

В интересах добавления большего количества ситуаций к этому вопросу (потому что именно там я смотрел, потому что у меня была такая же проблема), вот мой ответ:

В моем случае я вырезал/вставлял текст из общей ошибки, говорящей фактически, если вы хотите увидеть, что неправильно, поместите

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

Итак, это должно было исправить это, но, конечно, нет! Моя проблема заключалась в том, что был < system.web > node несколько строк выше (перед компиляцией и аутентификацией node) и закрывающий тег </system.web > несколько строк ниже. Как только я исправил это, ОК, проблема решена. То, что я должен был сделать, это скопировать/вставить только эту строку:

<customErrors mode="Off"/>

Это из летописей тупых вещей, которые я продолжаю делать снова и снова. В главе "Копировать и вставить свой путь к уничтожению".

Для приложений Sharepoint 2010 вы также должны отредактировать C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.config и определить <customErrors mode="Off" />

Один ответ, который действительно работал, чтобы исправить это, я нашел здесь: https://stackoverflow.com/questions/18291550/404-handling-in-azure-website

Просто добавьте это в свой web.config:

<configuration>  
  <system.webServer>  
    <httpErrors existingResponse="PassThrough"/>  
  </system.webServer>  
<configuration>

Я пробовал большую часть описанного здесь материала. Я использовал VWD, а файл web.config по умолчанию:

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

Я изменил режим = "RemoteOnly" в режим = "Выкл.". Еще нет радости. Затем я использовал диспетчер IIS, свойства, вкладку ASP.Net, "Изменить конфигурацию", затем выбрал вкладку CustomeErrors. Это все еще показало RemoteOnly. Я изменил это на Off и, наконец, я смог увидеть подробные сообщения об ошибках.

Когда я осмотрел web.config, я увидел, что в system.web есть два узла CustomErrors; и я только что заметил, что вторая запись (та, которую я менял, была внутри комментария). Поэтому старайтесь не использовать блокнот для проверки web.config на удаленном сервере.

Однако, если вы используете файл конфигурации редактирования IIS, он будет жаловаться на ошибки в web.config. Тогда вы можете исключить все ответы, в которых говорится: "Есть ли синтаксическая ошибка XML в вашем web.config"

Обычно вы можете найти дополнительную информацию об ошибке в средстве просмотра событий, если у вас есть к ней доступ. Ваш провайдер также может запретить отображение пользовательских ошибок вообще, либо переопределив его в файле machine.config, либо установив атрибут retail в true (http://msdn.microsoft.com/en-us/library/ms228298(VS.80).aspx).

Моя проблема заключалась в том, что я определил это в моем web.config

<httpErrors errorMode="Custom" existingResponse="Replace">
  <remove statusCode="404" />
  <remove statusCode="500" />
  <error statusCode="404" responseMode="ExecuteURL" path="/Error/NotFound" />
  <error statusCode="500" responseMode="ExecuteURL" path="/Error/Internal" />
</httpErrors>

У меня также была эта проблема, но при использовании Apache и mod_mono. Для всех остальных в этой ситуации вам необходимо перезапустить Apache после изменения web.config, чтобы заставить новую версию читать.

Если вы по-прежнему получаете эту страницу, вероятно, она взорвалась, прежде чем пройти через Web.Config

Убедитесь, что ASP.Net имеет разрешения, необходимые для таких вещей, как папки .Net Framework, метабаза IIS и т.д. Есть ли у вас какой-либо способ проверить, правильно ли установлен ASP.Net и правильно ли он связан с IIS?

Редактировать: После того, как Грег прокомментировал это, я предположил, что то, что вы опубликовали, было вашим очень минимальным web.config, есть что-то еще? Если да, можете ли вы опубликовать весь web.config?

Мы также столкнулись с этой ошибкой, и в нашем случае это произошло потому, что пользователь пула приложений больше не имел прав доступа к файлу web.config. Причина, по которой он потерял свои права (все было хорошо до этого), состояло в том, что у нас была резервная копия сайта в rar файле, и я перетащил резервную версию web.config из rar на сайт. Кажется, что удалены все разрешения для файла web.config, кроме меня, зарегистрированного пользователя.

Нам потребовалось некоторое время, чтобы понять это, потому что я неоднократно проверял разрешения на уровне папок, но никогда на уровне файлов.

У нас была эта проблема, и это произошло из-за того, что пользователь IIS не имел доступа к конфигурации компьютера на веб-сервере.

Собственно, то, что я выяснил при размещении моего веб-приложения, - это код, который вы разработали на своей локальной машине, имеет более высокую версию, чем предлагает вам хостинговая компания. Если у вас есть права администратора, вы можете изменить поддержку версии Microsoft ASP.NET в настройках веб-хостинга

У меня была такая же проблема, но я нашел решение по-другому.

-

Что я сделал, я открыл Дополнительные настройки для Пула приложений в Диспетчере IIS.

Там я установил Включить 32-разрядные приложения на True.

Я только что занимался подобной проблемой. В моем случае версия asp.net по умолчанию для сайта была 1.1, в то время как я пытался запустить веб-приложение 2.0. Ошибка была довольно тривиальной, но не сразу стало понятно, почему пользовательские ошибки не исчезнут, а время выполнения никогда не записывается в журнал событий. Очевидное исправление должно соответствовать версии на вкладке Asp.Net IIS.

Вы также можете попробовать открыть веб-сайт в браузере на серверной машине. Я не занимаюсь разработкой ASP.NET, но помню, что в настройках пользовательских ошибок есть параметр для отображения полного текста ошибки на сервере в качестве меры безопасности.

Это веб-приложение установлено под любыми другими приложениями в дереве каталогов веб-сайта? Проверьте любые родительские файлы web.config для других параметров, если они есть. Кроме того, сделайте свой каталог установленным как каталог приложения в IIS.

Если вы используете предварительный просмотр MVC 4, вы можете столкнуться с этим, потому что используете HandleErrorAttribute. Поведение изменилось в 5, так что оно не обрабатывает исключения, если вы отключите пользовательские ошибки.

Есть ли у вас какой-либо особый символ, например æøå в вашем web.config? Если это так, убедитесь, что для кодировки установлено значение utf-8.

Попробуйте перезапустить приложение (создание app_offline.htm, чем его удаление), и если вы все равно получите одно и то же сообщение об ошибке, убедитесь, что вы только объявили customErrors один раз в файле web.config или что-то в этом роде. Ошибки в файле web.config могут иметь какое-то странное влияние на приложение.

Для меня это была ошибка выше в web.config над system.web.

файл, бла, не существовал, поэтому в тот момент он выдавал ошибку. Поскольку он еще не попал в раздел System.Web, он использовал настройку сервера по умолчанию для CUstomErrors (On)

Это действительно странно. Я получил эту ошибку и после перезагрузки моего сервера он исчез.

В некоторых случаях также возможно, что web.config не отформатирован правильно. В этом случае вам придется пройти через линию, чтобы она работала. Часто правила перезаписи являются виновниками здесь.

У меня была такая же проблема, и я просмотрел журнал приложений для просмотра событий, где он четко упоминает, из-за чего это исключение. В моем случае исключение было следующим:

Информация об исключении:

Exception type: HttpException 
Exception message: The target principal name is incorrect.  Cannot generate SSPI context.
at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

The target principal name is incorrect.  Cannot generate SSPI context.

Я только что обновил свой пароль в пуле приложений, и он работает для меня.

Попробовав все ответы здесь, оказалось, что мой метод Application_Error имел это:

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

Удаление этих строк и установка исправили проблему. (Клиент по-прежнему перенаправляется на страницу с ошибкой customErrors="On").

Если вы выполняете конфигурационное преобразование, вам также может потребоваться удалить следующую строку из соответствующего файла web.config.

<compilation xdt:Transform="RemoveAttributes(debug)" />

Также убедитесь, что вы редактируете web.config, а не website.config, как и я.

Убедитесь, что вы добавили    сразу после system.web

Я положил его в конец node и не работал.

У меня была та же проблема, и причина в том, что в IIS был запущен ASP.NET 1.1, а на сайте -.NET 2.0.

Сообщение об ошибке ничего не делало, но меня выкидывало несколько часов.