CustomErrors mode = «Off»

Я получаю сообщение об ошибке каждый раз, когда загружаю свое веб-приложение провайдеру. Из-за режима customErrors все, что я вижу, - это сообщение об ошибке «Runtime error» по умолчанию, предлагающее мне отключить customErrors, чтобы больше узнать об ошибке.

Раздраженный, я установил свой web.config так:

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

И все же, все, что я получаю, это глупая страница с ошибками без полезной информации. Что еще я могу сделать, чтобы выключить customErrors ?!

Последние несколько дней это сводило меня с ума, и я не мог обойти это, но, наконец, понял это:

В моем файле machine.config у меня была запись под <system.web>:

<deployment retail="true" />

Кажется, это переопределяет любые другие параметры customError, которые вы указали в файле web.config, поэтому установите для приведенной выше записи:

<deployment retail="false" />

теперь означает, что я могу снова увидеть подробные сообщения об ошибках, которые мне нужны.

machine.configРасположен в

32-битный

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

64-битный

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

Надеюсь, что это поможет кому-то там и сэкономит несколько часов причесывания.

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

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

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

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

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

Так что это должно было исправить это, но, конечно, нет! Моя проблема заключалась в том, что был узел <system.web> на несколько строк выше (перед узлом компиляции и аутентификации) и закрывающий тег </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" />

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

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

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

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

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

Единственный ответ, который действительно работал, чтобы исправить это, я нашел здесь: https://stackoverflow.com/a/18938991/550975

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

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

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

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

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

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

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

Моя проблема заключалась в том, что я определил это в моем 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>

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

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

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

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

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

-

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

Там я установил Enable 32-Bit Applications на True .

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

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

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

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

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

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

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

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

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

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

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

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

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

Перепробовав все ответы здесь, выяснилось, что мой Application_Errorметод имел следующее:

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

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

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

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

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.

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

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

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

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

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