Problemy z aplikacjami sieci Web (błędy web.config) HTTP 500.19 z IIS7.5 i ASP.NET v2

To doprowadza cały zespół do szaleństwa. Musi istnieć jakaś prosta źle skonfigurowana część usług IIS lub naszego serwera internetowego, ale za każdym razem, gdy próbujemy uruchomić aplikację internetową ASP.NET w usługach IIS 7.5, otrzymujemy następujący błąd ...

Oto pełny błąd:

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration  
data for the page is invalid.

`Detailed Error Information` 
Module              IIS Web Core
Notification        Unknown
Handler             Not yet determined
Error Code          0x8007000d
Config Error
Config File         \\?\E:\wwwroot\web.config
Requested URL       http://localhost:80/Default.aspx
Physical Path 
Logon Method        Not yet determined
Logon User          Not yet determined
Config Source
   -1: 
    0: 

Na komputerze działa system Windows Server 2008 R2 . Opracowujemy naszą aplikację internetową przy użyciu programu Visual Studio 2008 .

Według Microsoftu kod 8007000d oznacza błąd składni w naszym pliku web.config - z wyjątkiem tego, że projekt buduje się i działa dobrze lokalnie. Przeglądanie pliku web.config w Notatniku XML również nie powoduje żadnych błędów składniowych. Zakładam, że to musi być jakaś kiepska konfiguracja z mojej strony ...?

Czy ktoś wie, gdzie mógłbym znaleźć dalsze informacje o błędzie? Nic nie jest wyświetlane w EventViewer :(

Nie wiem, o czym jeszcze warto wspomnieć ...

Pomoc jest bardzo ceniona. Dzięki!

AKTUALIZACJE! - OPUBLIKOWANA KONFIGURACJA PONIŻEJ

Ok, ponieważ powyżej opublikowałem pierwotne pytanie, wyśledziłem dokładne wiersze w pliku web.config , które powodowały błąd.

Oto linie (pojawiają się między <System.webServer>tagami) ...

    <httpHandlers>
        <remove verb="*" path="*.asmx"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </httpHandlers>

Uwaga: Jeśli mogę usunąć linie pomiędzy tym <httpHandlers>wciąż pojawia się błąd. Dosłownie muszę usunąć <httpHandlers>(i linie między nimi), aby przestać otrzymywać powyższy błąd.

Jednak gdy już to zrobię, pojawia się nowy błąd 500.19. Na szczęście tym razem IIS mówi mi, który fragment pliku web.config powoduje problem ...

    <handlers>
        <remove name="WebServiceHandlerFactory-Integrated"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </handlers>

Patrząc na te wiersze, widać, że problem został przeniesiony dalej w ramach tego samego <system.webServer>tagu do <handlers>tagu.

Nowy błąd jest również bardziej wyraźny i wyraźnie narzeka, że ​​nie rozpoznaje atrybutu „validate” (jak widać w trzeciej linii powyżej). Usunięcie tego atrybutu powoduje następnie narzekanie, że ta sama linia nie ma wymaganego atrybutu „nazwa”. Dodanie tego atrybutu powoduje następnie wyświetlenie błędu ASP.NET ...

Nie można załadować pliku lub zestawu „System.web.Extensions, Version = 1.0.61025.0, Culture = neutral, PublicKeyToken = f2cb5667dc123a56” lub jednej z jego zależności. System nie może odnaleźć określonego pliku.

Oczywiście wydaje mi się, że te nowe błędy powstały właśnie dzięki usunięciu <httpHandlers>tagów w pierwszej kolejności - są one oczywiście potrzebne aplikacji - więc pozostaje pytanie: dlaczego te tagi miałyby w pierwszej kolejności wywoływać błąd w usługach IIS? ??

Czy muszę coś zainstalować w usługach IIS, aby działało z nimi?

Jeszcze raz dziękuję za wszelką pomoc.

WEB.CONFIG

Oto kłopotliwe fragmenty naszej sieci. Konfiguruj ... Mam nadzieję, że pomoże to komuś znaleźć nasz problem!

<system.Web>

<!-- stuff cut out -->

    <httpHandlers>
        <remove verb="*" path="*.asmx"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56" validate="false"/>
    </httpHandlers>
    <httpModules>
        <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </httpModules>
</system.web>

<system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules>
        <add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </modules>
    <remove verb="*" path="*.asmx"/>
    <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    <handlers>
        <remove name="WebServiceHandlerFactory-Integrated"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </handlers>
</system.webServer>

Miałem dokładnie te objawy i mój problem był podobny do Petera. Konfigurowałem istniejący projekt na nowym serwerze. Mój projekt odwoływał się do modułu ponownego zapisywania adresów URL usług IIS7, ale nie został on jeszcze zainstalowany na nowym serwerze. Zainstalowanie go rozwiązało mój problem.

Aby go zainstalować, możesz użyć Instalatora platformy sieci Web firmy Microsoft . Uruchom go, wybierz Produkty , w lewym menu wybierz Serwer i znajdź na liście URL Rewrite i zainstaluj.

Możesz też pobrać go tutaj .

Po całodziennej walce z tym na nowej maszynie natrafiłem na poniższe linki. Brakowało mi przepisywania modułów. To naprawiło wszystko.

http://forums.iis.net/t/1176834.aspx

http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/

Aha! Pokonałem ten problem! Mój Boże, to była bestia dla kogoś takiego jak ja z ograniczonym doświadczeniem w IIS. Naprawdę myślałem, że spędzę cały weekend na naprawianiu tego.

Oto rozwiązanie dla każdego, kto kiedykolwiek napotka ten zły problem.

Pierwsza rzecz, o której należy pamiętać: jeśli masz nadzieję, że to jest Twoje rozwiązanie, upewnij się, że masz ten sam kod błędu ( 0x8007000d ) i źródło konfiguracji ( -1: 0 :) . Jeśli nie, to nie jest twoje rozwiązanie.

Następna rzecz, o której należy pamiętać: AJAX nie jest poprawnie zainstalowany w twoim web.config!

Napraw to, postępując zgodnie z tym przewodnikiem:
http://www.asp.net/AJAX/documentation/live/ConfiguringASPNETAJAX.aspx

Następnie zainstaluj rozszerzenia AJAX 1.0 na serwerze produkcyjnym, korzystając z tego linku:

http://www.asp.net/ajax/downloads/archive/
Aktualizacja : wydaje się, że Microsoft usunął powyższą stronę :(

Otóż ​​to!

Ten sam problem na serwerze 2016, IIS 10, błąd 500,19. Zainstalowałem moduł przekierowania i zadziałał. Nie wiem, dlaczego nie zostało to uwzględnione domyślnie.

https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads

Dla jasności wygląda na to, że plik web.config z IIS 7 będzie działał lub jest przeznaczony do pracy, ale brak tego modułu powoduje naprawdę dziwny i nieprzydatny błąd. Wyszukiwanie w Google prowadzi do strony firmy Microsoft, która twierdzi, że witryna jest uszkodzona lub plik web.config jest uszkodzony. Wydaje się, że tak nie jest.

Ta nieprzydatna strona jest tutaj: https://support.microsoft.com/en-us/kb/942055

Wystąpił ten sam problem co powyżej, ten sam kod błędu itp. Konfigurowanie lokalnej witryny internetowej w systemie Windows 8. Po wielu poszukiwaniach okazało się, że brakuje nam przepisywania adresu URL. Po pobraniu wszystko było w porządku. :)

Po prostu dodaję odpowiedź, ponieważ spędziłem godziny próbując rozwiązać te same objawy (ale inny problem):

Możliwą przyczyną jest dll x86 w 64-bitowej puli aplikacji, rozwiązaniem jest włączenie aplikacji 32-bitowych w ustawieniach puli aplikacji.

Dla mnie ponowna rejestracja asp.net dla iis załatwiła sprawę. Mam nadzieję, że to pomoże komuś innemu.

aspnet_regiis.exe -i

Podsumowując na podstawie odpowiedzi tutaj i gdzie indziej:

1. Sprawdź wersję .NET puli aplikacji (np. 2.0 vs 4.0)
2. Sprawdź, czy są zainstalowane wszystkie wymienione moduły usług IIS. W tym przypadku były to rozszerzenia AJAX (prawdopodobnie obecnie nie ma to miejsca), ale przepisywanie adresów URL jest powszechne.

Innym sposobem na uzyskanie errotu 500.19 bez wyraźnego powodu jest brak katalogów i / lub zepsute uprawnienia do nich.

W przypadku tego pytania wydaje mi się, że dotyczy ono pełnej wersji IIS. Zakładam to z powodu tej linii:

Config File         \\?\E:\wwwroot\web.config

Instalator usług IIS zwykle tworzy wwwrootza Ciebie i jest to domyślny folder główny dla wszystkich witryn sieci Web i punkt montowania dla katalogów wirtualnych. Zawsze istnieje, więc nie ma problemu, zwykle nie przejmujesz się tym.

Ponieważ pliki web.config są hierarchiczne, możesz umieścić tam główny plik web.config i mieć tam pewne ustawienia roota, a wszystkie witryny odziedziczą go. IIS sprawdza, czy ten plik istnieje i próbuje go załadować.

Jednak pierwsza fajna część:

Ten katalog będzie istniał, jeśli masz poprawnie zainstalowane usługi IIS. Jeśli nie istnieje, otrzymasz błąd klasy 500. Jeśli jednak grasz z uprawnieniami do plików / katalogów, zwłaszcza z uprawnieniami „zaawansowanymi”, możesz przypadkowo odmówić kontu usługi IIS skanowania / odczytywania zawartości tego katalogu. Jeśli usługi IIS nie mogą sprawdzić, czy adres wwwroot \ web.config istnieje lub czy istnieje, a usługi IIS nie mogą go otworzyć i odczytać - bam - błąd klasy 500.

Jednak w przypadku pełnych usług IIS jest to mało prawdopodobne. Deweloperzy / administratorzy pracujący z pełnymi usługami IIS są zwykle niechętni do grania, wwwrootwięc zazwyczaj pozostaje on poprawnie skonfigurowany.

Jednak w usługach IIS Express ..

Zwykle IIS Express „po prostu działa”. Często deweloperzy korzystający z usług IIS Express często nie zdają sobie sprawy, jak bardzo przypomina on wewnętrznie prawdziwe usługi IIS.

Możesz łatwo natknąć się na fakt, że IIS Express ma własny plik applicationHost.config, a VS tworzy go i zarządza nim za Ciebie (poprawnie, do pewnego stopnia), a tego rodzaju otwieracz do oczu mówi ci, że to nie jest takie proste i nie jest takie proste. i kliknij, jak się wydaje na początku.

Oprócz tego pliku konfiguracyjnego VisualStudio tworzy również pustą strukturę katalogów w Documentsfolderze. Jeśli dobrze pamiętam, IIS Express traktuje te foldery jako katalogi główne witryn internetowych, w których są montowane katalogi wirtualne z Twoim kodem.

Później, podobnie jak IIS, podczas uruchamiania IIS Express oczekuje , że te foldery istnieją i sprawdza, czy są tam główne pliki web.config. Witryny web.config plików. Niemal zawsze brakuje tych plików web.config - i to jest OK, ponieważ ich nie chcesz - masz swoją ** aplikację web.config ”, są one umieszczane z resztą treści w katalogach wirtualnych.

A teraz druga zabawna część: IIS Express oczekuje, że katalogi są puste. Mogą być puste, ale muszą istnieć. Jeśli nie istnieją - pojawi się błąd klasy 500 informujący, że nie można uzyskać dostępu do pliku „web.config” w tej ścieżce.

Pierwszy raz napotkałem ten problem podczas czyszczenia dysku twardego. Okazało się, że folder „dokumenty \ strony internetowe”, pełen śmieci, rozpoznałem kilkuletnie projekty, nad którymi już nie pracuję, wszystkie puste, ani jeden plik, więc wszystko skasowałem. Tydzień później - bam - nie mogę uruchomić / debugować żadnej z witryn, na których w tej chwili pracowałem. Błąd 500,19, nie można odczytać pliku konfiguracyjnego.

Tak więc, jeśli używasz IIS Express i widzisz błąd klasy 500 informujący o odczytaniu konfiguracji, uważnie sprawdź komunikat o błędzie i przeczytaj wszystkie wspomniane ścieżki. Jeśli zobaczysz coś takiego:

c:\users\user\documents\visual studio 2013\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2015\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2017\projects\WebProject1\WebProject1.web\web.config
etc..

Udaj się tam dokładnie tam, gdzie wskazuje błąd, upewnij się, że te foldery istnieją, upewnij się, że konto pracownika usług IIS może je przeglądać i czytać, a jeśli zauważysz, że coś jest nie tak, może to być to.

BTW. W VisualStudio w ProjectProperties / Web znajduje się przycisk „Utwórz katalog wirtualny”. Zasadniczo robi to dokładnie, więc możesz spróbować najpierw, ale IIRC może również czasami wyczyścić / nadpisać / zamienić sekcje konfiguracyjne w pliku applicationHost.config, więc bądź ostrożny z tym przyciskiem, jeśli masz tam jakieś niestandardowe ustawienia.

W moim przypadku coś było nie tak z instalacją pakietu .NET Core Windows Hosting Bundle.

Zainstalowałem to i ponownie uruchomiłem IIS przy użyciu („net stop was / y” i „net start w3svc”) po instalacji, ale otrzymałem ten błąd 500.19 z kodem błędu 0x8007000d i źródłem konfiguracji -1: 0 :.

Udało mi się rozwiązać ten problem, naprawiając instalację pakietu .NET Core Windows Hosting Bundle i ponownie uruchamiając IIS za pomocą poleceń, o których wspomniałem powyżej.

Mam nadzieję, że to komuś pomoże!

Ten piękny szczegółowy błąd jest nadal obecny w 2019 roku! Chcę tylko dodać, że jeśli twój web.configjest ważny i dostępny, najprawdopodobniej jest to kwestia zależności .

Jak wspomniano w PO, był to AJAXmoduł, a jak przez innych powszechnie Rewritemoduł. Po prostu miej oczy szeroko otwarte w pliku web.config, do jakich modułów i bibliotek odnoszą się twoje tagi, ponieważ kod błędu 0x8007000d może dotyczyć DOWOLNEJ zależności .

W moim przypadku nie zdawałem sobie sprawy, że AspNetCorebrakuje pakietu i trzeba go było zainstalować! Tak się cieszę, że znalazłem ten post !!

To może być powiązane lub nie ... Zacząłem od tego samego błędu, o którym mowa powyżej, zacząłem googlować, wprowadzać zmiany, otrzymywać nowe błędy, nieskończoną pętlę.

Zmiana, która spowodowała ten błąd, powodowała zamieszanie z delegowaniem funkcji w Menedżerze usług IIS w sekcji Zarządzanie na serwerze. Przepraszam, że nie pamiętam, który zmieniłem, ale wyszukiwanie w Google może pomóc.

To sprawiło, że przekroczyłem pierwszy błąd i wszedłem w zupełnie nowy strumień innych, niektóre całkowicie bezsensowne. (Wystąpił jeden błąd podczas pracy w katalogu wirtualnym, konwersja do aplikacji skutkowała innym błędem, etec itp.). Tym, co ostatecznie rozwiązało tę serię błędów, było: menedżer IIS, pule aplikacji, domyślna pula aplikacji, włącz aplikacje 32-bitowe = prawda

Uruchomiłem tę aplikację na 32-bitowym pudełku z systemem Windows XP, a teraz uruchamiam ją na 64-bitowym pudełku z systemem Windows 7.

Miejmy nadzieję, że pomoże to komuś innemu.

Moje IIS 7.5 nie rozumie tagu w web.config W VS 2010 jest również podkreślony ten tag. Sprawdź poprawność pliku konfiguracyjnego, aby znaleźć wszystkie podkreślone tagi. Umieszczam to w komentarzu i błąd znika.

Skomentuj następujące wiersze w pliku web.config.

<modules>
    <!--<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</modules>

<handlers>
    <remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
    <!--<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add name="ScriptResource" verb="GET" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</handlers>

To zadziała.

Miałem ten sam błąd. Miałem witrynę IIS z platformą .net w wersji 2.0, ale moja aplikacja wymagała 4.0. Zmieniłem wersję i zadziałało.

Publikowanie jako przypomnienie, jeśli ktoś może mieć ten sam problem.

Upewnij się, że wszystkie funkcje usług IIS są prawidłowo włączone.

• Otwórz funkcje systemu Windows (włącz lub wyłącz funkcje systemu Windows).

• Przewiń w dół do Internetowych usług informacyjnych

• Otwórz listę rozwijaną World Wide Web plus

• Otwórz listę rozwijaną Application Development Features plus
• Ręcznie zaznacz wszystkie kolejne pola wyboru, a następnie kliknij OK

Poniższa konfiguracja była przyczyną mojego problemu:

    <rewrite>
      <rules>
        <clear />
        <rule name="Redirect to HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^.*spvitals\.com$" />
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite>

Uwaga: usunąłem tę sekcję do testów lokalnych, ponieważ działa dobrze na platformie Azure.

Miałem ten sam problem w systemie Windows 7.

Rozwiązaniem było przejście do ustawień podstawowych> połączenie jako> określony użytkownik - i zalogowanie się jako użytkownik, zamiast domyślnego „pass-through”

To rozwiązało problem.

System Windows 7

Spróbuj tego,

uruchom cmd jako Admin.

Odinstaluj wszystkie iis.

start /w pkgmgr.exe /uu:IIS-WebServerRole;WAS-WindowsActivationService

Zainstaluj ponownie iis i normalnie to działa

Alain

Otrzymałem ten błąd, umieszczając <customErrors>tag w środku <system.webServer>zamiast w <system.web>miejscu, w którym należy. Pod metką było małe zawijanie, <customErrors>ale nie zauważyłem tego od razu.

Podobnie jak w przypadku pierwszej odpowiedzi , otrzymaliśmy ten niesamowicie nieprzydatny wyjątek z powodu brakującego modułu IIS CORS. To był dokładnie ten sam błąd z kodem błędu (0x8007000d) i źródłem konfiguracji (-1: 0 :), ale zainstalowanie modułu ponownego zapisywania adresów URL go nie naprawiło.

Niedawno zaktualizowaliśmy plik web.config, aby włączyć CORS dla niektórych programistów, którzy go potrzebowali, ale nie spodziewaliśmy się, że wszyscy deweloperzy będą musieli zainstalować moduł IIS CORS. Niestety wygląda na to, że jest to wymagane.

Aby to naprawić, zainstaluj stąd moduł IIS CORS .

W przypadku wdrażania aplikacji asp.net.core należy również zainstalować pakiet hostingu .net core. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/index?view=aspnetcore-3.0#install-the-net-core-hosting-bundle