Tryb CustomErrors = „Wył.”

Za każdym razem, gdy przesyłam aplikację internetową do dostawcy, pojawia się błąd. Ze względu na tryb customErrors wszystko, co widzę, to domyślny komunikat „Błąd w czasie wykonywania”, instruujący mnie, aby wyłączyć customErrors, aby wyświetlić więcej informacji o błędzie.

Zirytowany, ustawiłem mój plik web.config tak, aby wyglądał następująco:

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

Mimo wszystko, dostaję tylko głupią stronę zdalnych błędów, na której nie ma użytecznych informacji. Co jeszcze mogę zrobić, aby wyłączyć niestandardowe błędy?

To doprowadzało mnie do szaleństwa przez ostatnie kilka dni i nie mogłem tego obejść, ale w końcu to rozgryzłem:

W moim pliku machine.config miałem wpis w <system.web>:

<deployment retail="true" />

Wydaje się, że zastępuje to wszelkie inne ustawienia niestandardowego błędu określone w pliku web.config, dlatego ustawienie powyższego wpisu na:

<deployment retail="false" />

teraz oznacza, że ​​mogę ponownie zobaczyć szczegółowe komunikaty o błędach, które muszę.

machine.configZnajduje się na

32-bitowy

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

64-bitowy

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

Mam nadzieję, że pomoże komuś tam i zaoszczędzi kilka godzin ciągnięcia włosów.

„Off” rozróżnia małe i wielkie litery.

Sprawdź, czy litera „O” jest zapisana wielkimi literami w pliku web.config, kilkakrotnie cierpiałem (tak proste, jak się wydaje)

Aby dodać do tego pytania więcej sytuacji (ponieważ właśnie tam szukałem, ponieważ miałem dokładnie ten sam problem), oto moja odpowiedź:

W moim przypadku wyciąłem / wkleiłem tekst z ogólnego błędu, mówiąc, że jeśli chcesz zobaczyć, co jest nie tak, wstaw

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

To powinno to naprawić, ale oczywiście nie! Mój problem polegał na tym, że kilka linii powyżej był węzeł <system.web> (przed węzłem kompilacji i uwierzytelniania), a tag zamykający </system.web> kilka wierszy poniżej. Gdy to naprawię, OK, problem rozwiązany. Powinienem był skopiować / wkleić tylko ten wiersz:

<customErrors mode="Off"/>

To pochodzi z annałów Głupich rzeczy, które wciąż robię w kółko, w rozdziale zatytułowanym „Kopiuj i wklej swoją drogę do zniszczenia”.

W przypadku aplikacji Sharepoint 2010 należy również edytować C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.configi definiować<customErrors mode="Off" />

Próbowałem większości opisanych tutaj rzeczy. Korzystałem z VWD, a domyślny plik web.config zawierał:

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

Zmieniłem mode = „RemoteOnly” na mode = „Off”. Wciąż nie ma radości. Następnie użyłem menedżera IIS, właściwości, karty ASP.Net, Edytuj konfigurację, a następnie wybrałem kartę CustomeErrors. To wciąż pokazywało RemoteOnly. Zmieniłem to na Wyłączone i wreszcie mogłem zobaczyć szczegółowe komunikaty o błędach.

Kiedy sprawdziłem web.config, zobaczyłem, że w systemie.web były dwa węzły CustomErrors; i właśnie zauważyłem, że drugi wpis (ten, który zmieniałem, był w komentarzu). Staraj się więc nie używać notatnika do sprawdzania pliku web.config na zdalnym serwerze.

Jeśli jednak użyjesz konfiguracji edycji IIS, narzeka on na błędy w pliku web.config. Następnie możesz wykluczyć wszystkie odpowiedzi, które mówią „czy w pliku web.config występuje błąd składni XML”

Jedną odpowiedź, która faktycznie działała, aby to naprawić, znalazłem tutaj: https://stackoverflow.com/a/18938991/550975

Po prostu dodaj to do web.config:

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

Więcej informacji na temat błędu można znaleźć w Podglądzie zdarzeń, jeśli masz do niego dostęp. Twój dostawca mógł również w ogóle zapobiec wyświetlaniu niestandardowych błędów, zastępując je w pliku machine.config lub ustawiając atrybut retail na wartość true ( http://msdn.microsoft.com/en-us/library/ms228298 ( VS.80) .aspx ).

Miałem również ten problem, ale podczas używania Apache i mod_mono. Dla każdej innej osoby w takiej sytuacji musisz ponownie uruchomić Apache po zmianie pliku web.config, aby wymusić odczytanie nowej wersji.

Jeśli nadal otrzymujesz tę stronę, prawdopodobnie wysadza się w powietrze przed przejściem do Web.Config

Upewnij się, że ASP.Net ma uprawnienia do takich rzeczy, jak foldery .Net Framework, metabaza IIS itp. Czy masz jakiś sposób sprawdzenia, czy ASP.Net jest poprawnie zainstalowany i poprawnie powiązany z IIS?

Edycja: Po komentarzu Grega przyszło mi do głowy, że założyłem, że to, co opublikowałeś, było bardzo minimalnym plikiem web.config, czy jest coś więcej? Jeśli tak, czy możesz opublikować cały plik web.config?

Mój problem polegał na tym, że miałem to zdefiniowane w moim pliku 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>

Właściwie to, co wymyśliłem podczas hostowania mojej aplikacji internetowej, jest kod opracowany na lokalnej maszynie w wyższej wersji niż oferuje to firma hostingowa. Jeśli masz uprawnienia administratora, możesz zmienić obsługę wersji Microsoft ASP.NET w ustawieniach hostingu

Wystąpił ten problem i był on spowodowany tym, że użytkownik IIS nie miał dostępu do konfiguracji komputera na serwerze WWW.

Wystąpił również ten błąd, aw naszym przypadku było to spowodowane tym, że użytkownik puli aplikacji nie miał już uprawnień do pliku web.config. Powodem, dla którego utracił swoje uprawnienia (wcześniej wszystko było w porządku), było to, że mieliśmy kopię zapasową strony w pliku rar i przeciągnąłem kopię zapasową pliku web.config z pliku rar na stronę. Wydaje się, że usunęło to wszystkie uprawnienia do pliku web.config oprócz mnie, zalogowanego użytkownika.

Zajęło nam to trochę czasu, ponieważ wielokrotnie sprawdzałem uprawnienia na poziomie folderu, ale nigdy na poziomie pliku.

Miałem ten sam problem, ale znalazłem rozwiązanie w inny sposób.

-

To, co zrobiłem, otworzyłem Ustawienia zaawansowane dla puli aplikacji w IIS Manager .

Tam ustawiłem Włącz aplikacje 32-bitowe na Prawda .

Spróbuj zrestartować aplikację (utworzenie app_offline.htm niż usunięcie spowoduje) i jeśli nadal pojawia się ten sam komunikat o błędzie, upewnij się, że customErrors zadeklarowałeś tylko raz w pliku web.config lub coś podobnego. Błędy w pliku web.config mogą mieć dziwny wpływ na aplikację.

Czy masz jakiś znak specjalny, taki jak æøå w swoim web.config? Jeśli tak, upewnij się, że kodowanie jest ustawione na utf-8.

Czy ta aplikacja internetowa jest ustawiona poniżej innych aplikacji w drzewie katalogów witryny? Sprawdź wszystkie nadrzędne pliki web.config pod kątem innych ustawień, jeśli takie istnieją. Upewnij się także, że twój katalog jest ustawiony jako katalog aplikacji w IIS.

Jeśli używasz podglądu MVC 4, może to być spowodowane tym, że korzystasz z HandleErrorAttribute. Zachowanie zmieniło się na 5, aby nie obsługiwał wyjątków, jeśli wyłączysz niestandardowe błędy.

Możesz także spróbować otworzyć stronę internetową w przeglądarce na serwerze. Nie robię dużo programowania ASP.NET, ale pamiętam, że niestandardowe błędy mają ustawienie wyświetlania tylko pełnego tekstu błędu na serwerze, jako środek bezpieczeństwa.

Właśnie poradziłem sobie z podobnym problemem. W moim przypadku domyślną wersją witryny asp.net była wersja 1.1, gdy próbowałem uruchomić aplikację internetową 2.0. Błąd był dość trywialny, ale nie było od razu jasne, dlaczego niestandardowe błędy nie zniknęły, a środowisko wykonawcze nigdy nie zapisywało dziennika zdarzeń. Oczywistą poprawką było dopasowanie wersji w zakładce Asp.Net IIS.

Upewnij się także, że edytujesz plik web.config, a nie website.config, tak jak ja.

Miałem ten sam problem, a przyczyną było to, że w IIS działał program ASP.NET 1.1, a witryna wymagała platformy .NET 2.0.

Komunikat o błędzie nic nie zrobił, ale zrzucił mnie z tropu na kilka godzin.

Upewnij się, że dodajesz zaraz po pliku system.web

Umieściłem go pod koniec węzła i nie działałem.

Jeśli wykonujesz transformację konfiguracji, może być również konieczne usunięcie następującego wiersza z odpowiedniego pliku web.config.

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

Po wypróbowaniu wszystkich odpowiedzi tutaj okazało się, że moja Application_Errormetoda ma to:

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

Usunięcie tych linii i ustawienie rozwiązało problem. (Klient nadal zostaje przekierowany na stronę błędu za pomocą customErrors="On").

Miałem ten sam problem i przejrzałem dziennik aplikacji Podglądu zdarzeń, w którym wyraźnie wspomniano, z powodu którego wyjątku tak się dzieje. W moim przypadku wyjątek był jak poniżej ...

Informacje o wyjątku:

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.

Właśnie zaktualizowałem swoje hasło w puli aplikacji i działa dla mnie.

W niektórych przypadkach jest również możliwe, że plik web.config nie jest poprawnie sformatowany. W takim przypadku musisz przejść przez nią wiersz po wierszu, zanim zacznie działać. Często winowajcą są przepisy przepisywania.

To naprawdę dziwne. Wystąpił ten błąd i po ponownym uruchomieniu mojego serwera zniknął.

Dla mnie był to błąd wyżej w pliku web.config powyżej pliku system.web.

plik bla nie istniał, więc w tym momencie zgłaszał błąd. Ponieważ jeszcze nie dotarł do sekcji System.Web, używał domyślnego ustawienia serwera dla CUstomErrors (On)