Nie można rozpocząć debugowania na serwerze internetowym. Nie można uruchomić debugowania ASP.NET VS 2010, II7, Win 7 x64

92

Używam programu Visual Studio 2010 (jako administrator), IIS 7 w systemie Windows 7 x64. Mogę uruchomić witrynę sieci Web ASP.NET w usługach IIS 7 bez debugowania, ale kiedy naciskam klawisz F5, aby ją debugować, otrzymuję:

Nie można rozpocząć debugowania na serwerze internetowym. Nie można rozpocząć debugowania ASP.NET. Więcej informacji można uzyskać, uruchamiając projekt bez debugowania.

Niestety łącze pomocy nie pomaga mi zbytnio i prowadzi do ogromnego drzewa rzeczy.

Sprawdziłem co następuje:

  • Wymagania bezpieczeństwa - nie przypominam sobie, żebym wcześniej robił coś specjalnego. Proces roboczy w usługach IIS7 to w3wp.exe. Mówi, że jeśli działa jako ASPNET lub USŁUGA SIECIOWA, muszę mieć uprawnienia administratora, aby go debugować. Jak mogę się dowiedzieć, czy muszę tutaj coś zmienić?

  • Strony właściwości witryny sieci Web> Opcje uruchamiania> Debugery> ASP.NET jest zaznaczona. Użyj serwera niestandardowego jest ustawiony na adres URL witryny (co działa bez debugowania).

  • Debugowanie jest włączone w web.config.

  • Aplikacja korzysta z ASP.NET 3.5 (ostatecznie chcę przejść na 4.0, ale muszę się zająć migracją).

  • Pula aplikacji: Klasyfikacja .NET AppPool (wypróbowano również DefaultAppPool).

Jakieś pomysły, w których mogę sprawdzić dalej?

Z pewnością nie powinno być tak trudno zainstalować IIS, VS, utworzyć witrynę internetową i rozpocząć testowanie?

Z góry dziękuję.

Dan C.
źródło
1
Żeby było jasne, że po uruchomieniu programu Visual Studio kliknąłeś go prawym przyciskiem myszy i wybrałeś opcję Uruchom jako administrator?
Aaron Carlson
Sprawdziłeś już ten link? msdn.microsoft.com/en-us/library/dwesw3ee.aspx
Aaron Carlson,
@Aaron, tak, mam VS ustawione tak, aby zawsze działało jako administrator.
Dan C
@Aaron, przejrzałem wyraźnie tę stronę i jej elementy podrzędne przed opublikowaniem tutaj i nie wyróżniało się nic, co musiałem zrobić. Mój system spełnia wymagania, a debugowanie jest włączone dla witryny. Nie mam systemu Windows Server 2003, więc nie wykonano tam konfiguracji usług IIS. Nie zmieniłem żadnych ustawień zabezpieczeń, ponieważ nie wiem, czy muszę.
Dan C
Nie jestem pewien, czy to pomaga, ale próbowałem utworzyć nową testową witrynę sieci Web ASP.NET 3.5 w programie VS 2010, dodałem ją do usług IIS 7 bez żadnych specjalnych konfiguracji i udało mi się ją poprawnie debugować. Coś z moją główną aplikacją, jak jest skonfigurowana w VS, IIS, a może nawet w systemie plików. Nie wiem tylko, od czego zacząć.
Dan C,

Odpowiedzi:

239

Spróbuj przejść do usług IIS i sprawdź, czy jest uruchomiona pula aplikacji, której używasz. Wiele razy wystąpi błąd, który zamyka pulę aplikacji. Wystarczy kliknąć prawym przyciskiem myszy i rozpocząć, a wszystko powinno być gotowe.

Trey Copeland
źródło
Dzięki, żałuję, że nie znalazłem tego postu w piątek! Basen został zatrzymany i napotykam pierwszy błąd
Christopher Cabezudo Rodriguez
W moim przypadku musiałem zezwolić na ASP.NET v4.0.30319 w ograniczeniach ISAPI i CGI
Adi,
15
+1 Zła nazwa użytkownika / hasło używane do uwierzytelniania puli aplikacji.
P.Brian.Mackey
3
W moim przypadku pula była już uruchomiona, ale po zatrzymaniu i ponownym uruchomieniu działała.
Serj Sagan
1
Dzięki. To rozwiązanie działało na mnie idealnie. Dodatkowo musiałem ponownie uruchomić pulę aplikacji.
Sunil
44

Okazuje się, że winowajcą był moduł IIS Url Rewrite . Zdefiniowałem regułę, która przekierowuje wywołania do Default.aspx (która była ustawiona jako strona początkowa witryny ) do katalogu głównego witryny, tak żebym mógł mieć kanoniczny adres URL strony głównej. Jednak najwyraźniej VS miał z tym problem i pomylił się. Ten problem nie wystąpił, gdy używałem Helicon ISAPI_Rewrite, więc nawet nie przyszło mi do głowy, aby to sprawdzić.

Skończyło się na stworzeniu zupełnie nowej strony internetowej od podstaw i stopniowym przenoszeniu projektów / plików do mojego rozwiązania i przebudowie mojego web.config, aż się tego dowiedziałem! Cóż, przynajmniej teraz mam nieco czystszą stronę korzystającą z .NET 4.0 (na razie mam nadzieję, że nie napotkam żadnych ścian) - ale co za ból!

Dan C.
źródło
6
Tak, ale musisz mieć pewność, że działa pula aplikacji, a także Twój portal.
Junior Mayhé
W tej notatce mój problem znajdował się w pliku web.config w: <applicationInitialization remapManagedRequestsTo = "/ App / splash.html" doAppInitAfterRestart = "true" lockAttributes = ""> <add initializationPage = "App / index.html" hostName = " CSI "lockItem =" true "/> </applicationInitialization>. Używałem tego do wyświetlania ekranu powitalnego podczas inicjowania aplikacji.
Nick
6
To było to dla mnie. Ten brzydki błąd powodowała reguła przepisywania wysyłająca cały ruch HTTP do HTTPS. Nie mogłem znaleźć żadnego sposobu, aby zachować regułę do debugowania.
Kat
Chciałem tylko dodać, że dla mnie było podobnie, ale przepisywanie SSL, które mieliśmy na myśli, to nasza ścieżka początkowa to localhost / nazwa aplikacji, ale ponieważ przekierowanie wysłało cię do localhost / appname , spowodowało błąd VS, ponieważ nie może obsłużyć przekierowania. . Znalezienie tego problemu zajęło nam godzinę +, ponieważ podczas lokalnego testowania w usługach IIS wszystko działało idealnie! ..
Liam Wheldon,
Ten sam problem tutaj (moduł ponownego zapisywania adresu URL usług IIS). Rozwiązuję to, przenosząc moje zasady do moich Web.Release.config. Zobacz weblogs.asp.net/srkirkland/… i stackoverflow.com/questions/11032868/… .
Swisher Sweet
42

Program Visual Studio podczas uruchamiania spróbuje (z jakiegoś powodu) uzyskać dostęp do adresu URL:

/debugattach.aspx

Jeśli masz regułę przepisywania, która przekierowuje (lub w inny sposób przechwytuje), powiedzmy, .aspxpliki, gdzie indziej, otrzymasz ten błąd. Rozwiązaniem jest dodanie tej sekcji na początku swojej web.config„s <system.webServer>/<rewrite>/<rules>sekcji:

<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
    <match url="^debugattach\.aspx" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="None" />
</rule>

Zapewni to złapanie tego konkretnego żądania, nic nie zrobisz i, co najważniejsze, zatrzyma wykonywanie, aby żadne inne reguły nie zostały uruchomione. Jest to solidne rozwiązanie, więc nie krępuj się zachować go w pliku konfiguracyjnym do produkcji.

Kirk Woll
źródło
1
to niestety nie zadziałało dla mnie osobiście, ale mogę sprawdzić, że jest to zdecydowanie jakiś problem z przepisywaniem, ponieważ skomentowałem sekcję przepisywania w web.config i mogę działać bez problemu.
Matt
Może zechcesz wypróbować rozwiązanie stąd: stackoverflow.com/a/30813200/375303 . U mnie działa jak urok.
jerhewet
Program Visual Studio będzie rejestrować błędy związane z DebugAttach.aspx tutaj:% UserProfile% \ AppData \ Local \ Temp \ Visual Studio Web Debugger.log (Jeśli nie masz tego pliku - lub jeśli jest to stary plik - problem prawdopodobnie nie jest powiązany z DebugAttach.aspx.)
Brandon S
W moim przypadku podstawowa przyczyna jest prawidłowa, ale nie rozwiązanie. Dla mnie to zadziałało: <location path="debugattach.aspx"> <system.webServer> <validation validateIntegratedModeConfiguration="false" /> <httpErrors errorMode="DetailedLocalOnly" existingResponse="PassThrough"> <clear /> </httpErrors> </system.webServer> </location>
Tasos K.
dla mnie problem wynikał z „/debugattach.aspx”, ale rozwiązaniem była również zmiana erroMode na „DetailedLocalOnly”.
Nashe
30

Z korzyścią dla innych w moim przypadku skonfigurowałem pulę aplikacji tak, aby korzystała z moich poświadczeń systemu Windows w celu uzyskania dostępu do udziału zasobów sieciowych. Od czasu ostatniego debugowania rozwiązania zresetowałem hasło systemu Windows. Zmienione hasło przechowywane w puli aplikacji i bada bing.

Breeno
źródło
Dzięki za to, że nawet nie korzystałem z udziału sieciowego, ale działało świetnie.
Marissa
21

Jeśli ApplicationPool Identity jest ustawione konto niestandardowe, a hasło komputera zostanie zmienione, musisz zaktualizować swoje hasło

Witaj świecie
źródło
Tak, miałem problem, wypróbowałem kilka odpowiedzi stąd bez rezultatu, twoja odpowiedź naprawdę mi pomogła!
Vadzim Savenok
19

W moim scenariuszu były to zmiany w sekcji httpErrors w web.config, ustawiając ją w następujący sposób:

<httpErrors mode="Custom"> 

spowodował błąd „Nie można rozpocząć debugowania na serwerze internetowym”. Przywrócenie poprzedniej wartości „DetailedLocalOnly” rozwiązało problem. Zagłębiając się nieco głębiej, odkryłem, że przyczyną tego było tylko ustawienie błędu 401:

<httpErrors mode="Custom"> 
    <error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom"> 

Skomentowanie linii błędu 401 również rozwiązało problem, poszedłem z tym, ponieważ mogę wtedy zachować niestandardową obsługę błędów i rozpocząć debugowanie.

Nadal nie mam pojęcia, dlaczego tak się dzieje.

Fjarskiptagervitungl
źródło
Z tej samej przyczyny, gdy próbowałem rozpocząć debugowanie, byłem świadkiem odpowiedzi 401 w moich dziennikach, a dezaktywacja domyślnej obsługi błędów rozwiązała problem „vs nie można debugować witryny”. Nie rozumiem, dlaczego 401 pojawia się nawet na mojej stronie logowania, kiedy i tylko podczas uruchamiania debugowania za pomocą vs, podczas gdy tylko anonimowy dostęp i uwierzytelnianie formularza internetowego. są aktywowane.
Frédéric
To była również poprawka dla mnie, tylko ja mam domyślną ścieżkę błędu ustawioną zamiast jawnie definiować jedną dla 401.
tuespetre
To właśnie zadziałało dla mnie (tymczasowo właśnie usunąłem całą sekcję httperrors). To, co wypróbowałem wcześniej, ale nie działało, to ponowne uruchomienie puli aplikacji i usunięcie reguł przepisywania adresów URL.
Nicholas Westby
To jest to, co mi pomogło. potem zmieniłem swój niestandardowy błąd, tak jak @Pablo Romeo napisał w tej odpowiedzi: stackoverflow.com/a/13905859/4489664
Bondaryuk Vladimir
2
Zmiana erroMode na „DetailedLocalOnly” również rozwiązała mnie. Debugger próbował otworzyć plik „/DebugAttach.aspx”, co spowodowało przejście do strony błędu niestandardowego, której nie mógł uruchomić w danym momencie.
Nashe
13

Sprawdź pulę aplikacji. jeśli zostanie zatrzymany. uruchom go ponownie.

user3206598
źródło
4
To to samo, co odpowiedź numer 1, która została zaproponowana miesiąc wcześniej.
mac10688
OK, to jest to, ale dlaczego za każdym razem się zatrzymuje?
Fernando Torres
Moja pula aplikacji działała na użytkowniku, który zmienił hasło.
Anderson
11

Miałem ten sam problem podczas próby debugowania modułu DNN (Dot Net Nuke). Okazało się, że musisz mieć debugowanie kompilacji = "true":

<compilation debug="true" strict="false" targetFramework="4.0"> 

w pliku web.config. Domyślnie w DNN jest fałsz. Oryginalne źródło tutaj: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Zar Shardan
źródło
Dziękuję Ci!! Wyrywałem sobie włosy przez cały dzień, a naprawa była taka prosta. Gdyby tylko VS mógł dać znaczący komunikat o błędzie!
colincameron
8

Mam dokładnie ten sam problem po wdrożeniu modułu przepisywania.

Jeśli usunę wpisy przepisywania z mojego pliku web.config, debugowanie działa idealnie.

Aby to obejść, po prostu skomentowałem przepisywanie znaczników podczas debugowania, na przykład ...

<rewrite>
    <rules>
        <rule name="LowerCaseRule_1" stopProcessing="true">
            <match url="[A-Z]" ignoreCase="false" />
            <action type="Redirect" url="{ToLower:{URL}}" />
        </rule>
        <rule name="RedirectDefault.aspx_1" stopProcessing="true">
            <match url="(.*)default.aspx" />
            <action type="Redirect" url="{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Następnie usuwam komentarze po debugowaniu.

To musi być błąd w programie Visual Studio 2010.

geofili
źródło
1
To prawda, jest to obejście, ale kiepskie, ponieważ bardzo łatwo jest zapomnieć o usunięciu takich komentarzy przed zatwierdzeniem lub opublikowaniem strony.
Jon Adams,
1
Możesz przenieść te linie w pliku konfiguracyjnym web.config.release, więc po opublikowaniu będzie on dostępny tylko w opublikowanej wersji. To jest to co zrobiłem.
shalke
Może po prostu wykluczenie /debugattach.aspx robi to. Spójrz na komentarz Petera
Monksa
6

Wystąpił ten sam błąd, ponieważ pula aplikacji została zatrzymana w usługach IIS. Po uruchomieniu puli aplikacji problem został rozwiązany.

Ovini
źródło
Rozwiązałem też mój problem! Dowiedziałem się, że moja pula DefaultAppPool została zatrzymana. Dzięki za udostępnienie tego. Nie mogę zrozumieć, dlaczego to się zatrzymało.
Jobert Enamno
5

Oto, co zrobiłem, aby usunąć zanotowany błąd. Zlokalizuj folder sieciowy aplikacji w systemie plików, przejdź do Właściwości => Zabezpieczenia kliknij przycisk Zaawansowane , a następnie kliknij kartę Właściciel , kliknij przycisk Edytuj i zmień właściciela (z odpowiednimi uprawnieniami) folderu i zaznacz opcjęOdnów właściciel na podkontenerach i obiektach ”. Kliknij „ Zastosuj ”, a następnie byłem w biznesie (mogłem debugować).

Mam nadzieję, że to zadziała dla kogoś innego.

Moe Howard
źródło
2
Zmienić właściciela na kogo?
dumbledad
5

W końcu naprawiłem to dla mojego pojedynczego rozwiązania, które to miało. Dwa projekty w rozwiązaniu zostały ustawione jako witryny w usługach IIS. Wszedłem i włączyłem personifikację ASP.Net w ramach uwierzytelniania dla obu projektów ... i VIOLA! WRESZCIE, koniec z tym irytującym błędem!

Todd Vance
źródło
3

Otrzymałem ten sam komunikat o błędzie w programie VS 2012, ale nie działałem jako administrator. Kiedy uruchomiłem aplikację jako administrator, otrzymałem inną i nieco bardziej pomocną wiadomość (którą udało mi się zrozumieć). HTH

Tom Gerken
źródło
3

Jeśli pula aplikacji ma problemy z ponownym uruchomieniem lub po prostu nie chce, aby ponownie uruchomić, sprawdź, czy system Windows wykonał ostatnią aktualizację w programie ASP.NET w wersji 4.0 lub innej puli aplikacji. Tak właśnie się stało w moim przypadku. Po prostu ponownie uruchomiłem komputer, a następnie ponownie uruchomiłem pulę aplikacji ASP.NET v4.0 i wszystko znów działało!

Chewbacca17
źródło
2

Dan,

Oprócz sugestii Aarona wypróbuj poniższe

  • Sprawdź, czy w witrynie internetowej usług IIS jest zaznaczone zintegrowane uwierzytelnianie systemu Windows
  • Czy możesz debugować za pomocą Cassini zamiast IIS?
Keefu
źródło
Wykonałem poniższe kroki, aby włączyć zintegrowane uwierzytelnianie systemu Windows: msdn.microsoft.com/en-us/library/x8a5axew.aspx, jednak nadal mam ten sam błąd (menedżer iis wyświetla ostrzeżenie, że nie mogę używać jednocześnie uwierzytelniania opartego na wyzwaniu i logowaniu - moja witryna korzysta z uwierzytelniania za pomocą formularzy). Mogę debugować witrynę za pomocą serwera WWW wbudowanego w VS 2010, ale brakuje w niej funkcji.
Dan C
Czy próbowałeś utworzyć nową witrynę internetową w usługach IIS i wdrożyć tam swój kod? Z ciekawości, jakich funkcji byś brakowało, gdybyś debugował w Cassini? O ile mi wiadomo, Cassini obsługuje uwierzytelnianie formularzy.
Keefu
Co masz na myśli mówiąc „tworzenie nowej witryny sieci Web w usługach IIS”? To jest nowy komputer z nowym systemem operacyjnym, VS2010, instaluje się IIS. Utworzyłem nową aplikację w IIS i skierowałem ją do folderu rzeczywistej witryny internetowej (pobranego z kopii zapasowej). Wydaje się, że funkcja ponownego zapisywania adresów URL nie działa w pełni w Cassini. Używamy również niestandardowego modułu do automatycznego przełączania między http i https ( codeproject.com/KB/web-security/WebPageSecurity_v2.aspx ).
Dan C,
Cassini nie obsługuje modułu
przepisywania adresu
2

Wystąpił ten sam problem z systemem Windows 10 po włączeniu wszystkich funkcji okien usług IIS. Przełączono na system Windows 8.1 i ponownie wystąpił problem. Katalog główny znajdował się w witrynie internetowej o nazwie „ http: //MySite.local ” (nie dotyczy wersji systemu operacyjnego).

A rozwiązanie jest proste

  • Edytuj plik hosts w %SystemRoot%\System32\drivers\etc\

  • Dodaj linię z powiązaniem IP: 127.0.0.1 MySite.local

Artru
źródło
To był dla mnie klejnot, zupełnie zapomniałem o ustawianiu mojego pliku hosta i zastanawiałem się, dlaczego mój interfejs API nie działa, kiedy przełączałem się na lokalny iis (dla https). VS działał tylko z jedną uruchomioną witryną, ale gdy dodałem drugą, nie mogłem już debugować, to rozwiązało problem.
CDerrig
1

Ten błąd wystąpił dzisiaj z powodu defektu w kodzie, który ogromnie wiele razy powodował zalewanie usług IIS żądaniami. To zasadniczo zablokowało IIS, więc kiedy próbowałem debugować, upłynął limit czasu podczas próby uruchomienia debugera. Po prostu ponownie uruchomiłem IIS, co zajęło kilka minut i rozwiązało problem.

Z pewnością chciałbym, żeby ten błąd był mniej ogólny, wydaje się, że istnieje kilka różnych sposobów jego utworzenia.

ammills01
źródło
1

Miałem ten sam problem w Visual Studio 2012 i 2013 na Windows 8.1. Dla mnie rozwiązaniem było dodanie uwierzytelniania systemu Windows do usług IIS za pomocą opcji „Włącz lub wyłącz funkcje systemu Windows”

Włącz lub wyłącz funkcje systemu Windows

dumbledad
źródło
1

Upewnij się, że pula aplikacji Twojej witryny używa poprawnej wersji struktury . Otrzymałem błąd „Nie można rozpocząć debugowania” w witrynie ASP.Net 2005. Błędnie korzystał z DefaultAppPool w systemie Windows 7 (który, jak sądzę, korzystał z .Net Framework 4). Utworzyłem nową pulę aplikacji w oparciu o .Net Framework 2 i przypisałem ją do witryny, w której występuje problem. Po tym debugowaniu działało dobrze.

DeveloperDan
źródło
1

Sprawdź, czy Twoja witryna internetowa w usługach IIS się nie kończy.

Naprawiłem to i uruchomiłem moją witrynę internetową. :RE

AFetter
źródło
1

Miałem ten problem i ostatecznie zdałem sobie sprawę, że I ASP.net nie jest poprawnie zarejestrowany w IIS. Może się to zdarzyć, gdy serwer IIS jest zainstalowany przed programem Visual Studio. Aby rozwiązać ten problem, użyj polecenia aspnet_regiis -i Więcej informacji można znaleźć w odsyłaczu

karpanai
źródło
1

miał ten sam problem. Jeśli masz zainstalowany certyfikat SSL w usługach IIS i próbujesz go debugować w programie Visual Studio, musisz ustawić aplikację w usługach IIS, aby ignorowała certyfikat.

akd
źródło
1

Miałem ten sam problem i stwierdziłem, że jest on spowodowany błędnym wpisaniem znaku Web.configpo tagu końcowym. My Web.configwyglądało to na samym końcu: </section>h. „H” był dodatkowym znakiem po zamykającym tagu.

Lavanya
źródło
0

usuń żądło w ten sposób: targetFramework = "4.0" w web.config lub zmień AppPool na odpowiednią wersję frameworka.

Slava
źródło
0

Odinstalowanie rozszerzenia IIS UrlScan rozwiązało problem za mnie.

Tomasz
źródło
0

Miałem ten sam problem, ale był to na własnym serwerze programistycznym Visual studios zamiast na IIS. Obejście polega na usunięciu zaznaczenia opcji na karcie Sieć we właściwościach projektu, Zastosuj ustawienia serwera do wszystkich użytkowników (zapisz w pliku projektu). Zaoszczędzi to komuś cenny czas.

user3169006
źródło
0

Miałem ten sam problem. Wszystkie powyższe odpowiedzi nie działają dla mnie. Rozwiązaniem było ręczne usunięcie folderu bin i obj.

user1949096
źródło
0

Znalazłem ten problem, ale był najbardziej podobny do tego, co wyjaśnił @Kirk i przepisywania adresu URL.

W moim przypadku ktoś sprawdził tę zmianę w pliku web.config dla projektu MVC:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".aspx" allowed="false" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

Ponieważ rozszerzenia plików .aspx nie były dozwolone na serwerze sieci Web, /debugattach.aspxadres URL został odrzucony, co uniemożliwiło uruchomienie debugera. Po usunięciu tej konfiguracji znowu zadziałało.

Peter Monks
źródło
0

Miałem ten sam problem, gdy tworzyłem aplikację w Visual Studio, a następnie we właściwościach utworzono katalog wirtualny do użytku z lokalnymi usługami IIS. Jeśli ktoś ma ten błąd, to dlatego, że VS tworzy aplikację w niewłaściwej puli aplikacji, czyli w puli aplikacji, która nie odpowiada Twoim potrzebom.
W takim przypadku przejdź do Menedżera IIS, wybierz aplikację, przejdź do ustawień podstawowych i zmień AppPool dla aplikacji i gotowe.

Wierzba
źródło
0

Niedawno dostałem ten sam błąd iw moim przypadku okazało się, że są zduplikowane typy MIME. Niedawno dodałem dwa, które początkowo nie pojawiły się na liście. IIS pozwoliło mi je dodać i dopiero wtedy, gdy zdecydowałem się ponownie sprawdzić typy MIME dla witryny w ramach mojego procesu diagnostycznego, również dostałem błąd w IIS. Odwołał się do duplikatów w pliku web.config. Kiedy wróciłem do pliku web.config, zauważyłem, że dodano nową sekcję o nazwie, która zawiera dwa ostatnio dodane typy MIME. Usunięto tę sekcję i życie znów jest dobre! Mając nadzieję, że może to pomóc innym, którym nie udało się rozwiązać problemu za pomocą żadnej z innych sugestii.

Mikrofon
źródło