CustomErrors mode= " Off"

"Off" rozróżnia wielkość liter.

Sprawdź, czy "O" jest wielką literą w Twojej sieci.plik config, kilka razy mi się to przytrafiło (tak proste jak się wydaje)

W trosce o dodanie kolejnych sytuacji do tego pytania (bo właśnie tam Szukałem, bo 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 w efekcie jeśli chcesz zobaczyć co jest nie tak, umieść

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

Więc to powinno to naprawić, ale oczywiście nie! Mój problem polegał na tym, że był system<.web> node kilka linii powyżej (przed węzłem kompilacji i uwierzytelniania) oraz znacznik zamykający kilka linijek poniżej. Kiedy to poprawiłem, OK, problem rozwiązany. Co powinienem zrobić to skopiować / wkleić tylko ten wiersz:

<customErrors mode="Off"/>

To jest z annałów głupich rzeczy, które ciągle robię w kółko, w rozdziale zatytułowanym "Kopiuj i wklej swoją drogę do zniszczenia".

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

Próbowałem większości opisanych tu rzeczy. Używałem VWD i domyślnej sieci.plik konfiguracyjny 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". Nadal nie ma radości. Następnie skorzystałem z Menedżera IIS, właściwości, ASP.Net Tab, Edytuj konfigurację, a następnie wybierz zakładkę CustomeErrors. To nadal pokazało RemoteOnly. Zmieniłem to na Wyłączone i w końcu mogłem zobaczyć szczegółowe komunikaty o błędach.

Kiedy sprawdzałem sieć.config widziałem, że w systemie były dwa węzły CustomErrors.www; a ja 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 sieci.config na zdalnym serwerze.

Jednakże, jeśli używasz konfiguracji edycji usług IIS, będzie to narzekać na błędy w sieci.config. Następnie możesz wykluczyć wszystkie odpowiedzi, które mówią " czy w Twojej sieci występuje błąd składni XML.config "

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

Po prostu dodaj to do swojego web.config:

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

Ogólnie można znaleźć więcej informacji na temat błędu w przeglądarce zdarzeń, jeśli masz do niego dostęp. Twój dostawca mógł również uniemożliwić wyświetlanie niestandardowych błędów poprzez zastąpienie ich na swoim komputerze.config, lub ustawienie atrybutu retail na true ( http://msdn.microsoft.com/en-us/library/ms228298 (VS.80). aspx).

Też miałem ten problem, ale przy używaniu Apache i mod_mono. Dla każdego innego w tej sytuacji, trzeba ponownie uruchomić Apache po zmianie web.config, aby wymusić odczyt nowej wersji.

Jeśli nadal otrzymujesz tę stronę, prawdopodobnie wybuchnie przed przejściem przez sieć.Config

Upewnij się, że ASP.Net posiada uprawnienia potrzebne do takich rzeczy jak foldery. Net Framework, Metabase IIS itp. Czy możesz to jakoś sprawdzić? ASP.Net czy jest poprawnie zainstalowany i powiązany w IIS?

Edit: po komentarzu Grega doszedłem do wniosku, że to, co zamieściłeś, to cała Twoja minimalna sieć.config, czy jest coś więcej? Jeśli tak można publikujesz całą sieć.config?

Mój problem polegał na tym, że miałem to zdefiniowane w mojej sieci.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 odkryłem podczas hostingu mojej aplikacji internetowej, to kod, który opracowałeś na lokalnej maszynie, jest wyższej wersji niż oferuje ci firma hostingowa. Jeśli masz uprawnienia administratora, możesz zmienić Microsoft ASP.NET Obsługa wersji w Ustawieniach Hostingu WWW

Mieliśmy ten problem i był on spowodowany tym, że użytkownik IIS nie miał dostępu do konfiguracji maszyny na serwerze WWW.

Również napotkaliśmy ten błąd i w naszym przypadku było to spowodowane tym, że użytkownik puli aplikacji nie miał uprawnień do sieci.plik konfiguracyjny. Powodem utraty uprawnień (wcześniej wszystko było w porządku) było to, że mieliśmy kopię zapasową witryny w pliku rar i przeciągnąłem kopię zapasową wersji sieci.config z rar na stronę. Wygląda na to, że usunięto wszystkie uprawnienia do sieci.plik konfiguracyjny oprócz mnie, zalogowanego użytkownika.

Trochę nam to zajęło 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.

-

Tam ustawiłem Enable 32-Bit Applications na True .

Spróbuj ponownie uruchomić aplikację (tworząc app_offline.htm niż usunięcie go zrobi), a jeśli nadal otrzymasz ten sam komunikat o błędzie, upewnij się, że zadeklarowałeś customErrors tylko raz w Internecie.config, czy coś w tym stylu. Błędy w sieci.config może mieć dziwny wpływ na aplikację.

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

Czy ta aplikacja jest ustawiona pod innymi aplikacjami w drzewie katalogów witryny? Sprawdź dowolną sieć nadrzędną.pliki konfiguracyjne dla innych ustawień, jeśli istnieją. Ponadto, upewnij się, że twój katalog jest ustawiony jako katalog aplikacji w IIS.

Jeśli używasz MVC preview 4, możesz tego doświadczyć, ponieważ używasz HandleErrorAttribute. Zachowanie zmieniło się w 5 tak, że nie obsługuje WYJĄTKÓW, jeśli wyłączysz błędy niestandardowe.

Możesz również spróbować wywołać stronę w przeglądarce na serwerze. Nie robię zbyt wiele ASP.NET rozwój, 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 miałem do czynienia z podobną kwestią. W moim przypadku Domyślna strona asp.net wersja była 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ą, a runtime nigdy nie napisał do dziennika zdarzeń. Oczywistą poprawką było dopasowanie wersji w Asp.Net zakładka IIS.

Upewnij się również, że edytujesz www.config a nie Strona WWW.config, tak jak robiłam.

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

Komunikat o błędzie nie zrobił nic, ale wyrzucić mnie z toru na kilka godzin.

Upewnij się, że dodajesz zaraz po systemie.web

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

Jeśli wykonujesz transformację config, może być również konieczne usunięcie poniższej linii z odpowiedniej sieci.plik konfiguracyjny.

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

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

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

Usunięcie tych linii i ustawienie naprawiło problem. (Klient nadal został przekierowany na stronę błędu z customErrors="On").

Miałem ten sam problem i przejrzałem dziennik aplikacji Event viewer, w którym wyraźnie wspomniano, z powodu którego wyjątku to się stało. W moim przypadku wyjątek był jak poniżej...

Informacje o wyjątkach:

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.

Jest to również możliwe w niektórych przypadkach, że web.config nie jest poprawnie sformatowany. W takim przypadku musisz przejść przez to linia po linii, zanim zadziała. Często winowajcą są tu zasady przepisywania.

To naprawdę dziwne. Dostałem ten błąd i po ponownym uruchomieniu serwera zniknął.

Dla mnie był to błąd wyżej w sieci.config nad systemem.www.

Plik nie istniał, więc w tym momencie był błąd. Bo jeszcze nie dostało się do systemu.Sekcja Web używała domyślnego ustawienia serwera dla CUstomErrors (On)

To może nie być IIS!

Przejrzałem wszystkie odpowiedzi na tej stronie, a także kilka innych. Żaden z nich nie rozwiązał naszego problemu, ale są dobre rzeczy do sprawdzenia i będą powodować problemy. Więc najpierw sprawdź te. Jeśli nadal wyrywasz włosy i używasz PHP, sprawdź ustawienia PHP.

Naprawiono dla mnie edytowanie naszego php.plik ini i podaj:

display_errors: On

Ustawiłem też:

display_startup_errors: On

To naprawiło problem, a nasz prawdziwy problem okazał się pominięty przecinek, który został pominięty podczas migracji dev to stage.

Zdaję sobie sprawę, że ta strona była połączona z asp.net, które również wykorzystywaliśmy, a to nie jest asp.net problem, ale gdy szukasz tych błędów, ta strona pojawia się i zawiera dobre informacje dotyczące naprawiania najczęstszych problemów; tylko nie nasz konkretny problem. Zmiany w konfiguracji naprawiły to, a potem mogliśmy skoncentrować się na naszym asp.net pliki!