Режим CustomErrors = "Вимкнено"

Я отримую помилку щоразу, коли завантажую свій веб-сайт постачальнику. Через режим customErrors все, що я бачу, - це повідомлення "Помилка виконання" за замовчуванням, яке вказує мені вимкнути 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>

Я змінив режим = "RemoteOnly" на режим = "Вимкнено". Ще немає радості. Потім я застосував менеджер IIS, властивості, вкладку ASP.Net, редагування конфігурації, а потім вибрав вкладку CustomeErrors. Це все ще показало RemoteOnly. Я змінив це на "Вимкнено" і, нарешті, побачив докладні повідомлення про помилки.

Коли я оглянув 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>

Як правило, ви можете знайти більше інформації про помилку в Переглядачі подій, якщо у вас є доступ до неї. Ваш постачальник може також не допустити відображення користувацьких помилок взагалі, перекривши їх у своїй машині.config, або встановивши атрибут роздрібної торгівлі на істинне ( 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 Manager .

Там я встановив Увімкнути 32-розрядні програми на 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 (Увімкнено)