web sunucusunda hata ayıklama başlatılamıyor. ASP.NET hata ayıklama VS 2010, II7, Win 7 x64 başlatılamadı

Windows 7 x64 üzerinde Visual Studio 2010 (Yönetici olarak), IIS 7 çalıştırıyorum. ASP.NET web sitesini IIS 7'de hata ayıklamadan sorunsuzca çalıştırabiliyorum, ancak hata ayıklamak için F5'e bastığımda şunu elde ediyorum:

web sunucusunda hata ayıklama başlatılamıyor. ASP.NET hata ayıklaması başlatılamadı. Hata ayıklama yapmadan projeyi başlatarak daha fazla bilgi edinilebilir.

Ne yazık ki yardım bağlantısı bana pek yardımcı olmuyor ve büyük bir ağaçtan aşağıya iniyor.

Aşağıdakileri kontrol ettim:

• Güvenlik gereksinimleri - Daha önce özel bir şey yapmak zorunda olduğumu hatırlamıyorum. IIS7'deki çalışan işlem w3wp.exe'dir. ASPNET veya NETWORK SERVICE olarak çalışıyorsa, hata ayıklamak için Yönetici ayrıcalıklarına sahip olmam gerektiğini söylüyor. Burada bir şeyi değiştirmem gerekip gerekmediğini nasıl anlarım?

• Web sitesi Özellik Sayfaları> Başlatma Seçenekleri> Hata Ayıklayıcıları> ASP.NET işaretlenir. Özel sunucu kullan, sitenin URL'sine ayarlanır (hata ayıklama olmadan iyi çalışır).

• İçinde hata ayıklama etkinleştirildi web.config.

• Uygulama ASP.NET 3.5 kullanıyor (Sonunda 4.0'a geçmek istiyorum, ancak ilgilenmem gereken bazı geçişlerim var).

• Uygulama havuzu: Sınıflandırma .NET AppPool (ayrıca DefaultAppPool denendi).

Daha sonra kontrol edebileceğim bir fikrin var mı?

Elbette IIS, VS'yi kurmak, bir web sitesi oluşturmak ve onu test etmeye başlamak o kadar da zor olmamalı?

Şimdiden teşekkürler.

IIS'ye gitmeyi deneyin ve kullandığınız Uygulama Havuzunun başlatıldığından emin olun. Çoğu zaman, uygulama havuzunu kapatan bir hata üretirsiniz. Sadece sağ tıklamanız ve Başlatmanız gerekir ve gitmeniz iyi olur.

Suçlu olanın IIS Url Yeniden Yazma modülü olduğu ortaya çıktı. Standart bir ana URL'ye sahip olabilmek için, Default.aspx'e ( web sitesinin başlangıç ​​sayfası olarak ayarlanan) çağrıları sitenin köküne yönlendiren bir kural tanımladım . Bununla birlikte, görünüşe göre VS'nin bununla bir sorunu vardı ve kafası karıştı. Helicon ISAPI_Rewrite kullanırken bu sorun olmadı, bu yüzden kontrol etmem bile aklıma gelmedi.

En sonunda sıfırdan yepyeni bir web sitesi oluşturdum ve projeleri / dosyaları yavaş yavaş çözümüme aktararak ve bunu bulana kadar web.config'imi yeniden oluşturdum! Eh, en azından şimdi .NET 4.0 kullanan biraz daha temiz bir sitem var (şimdiye kadar umarım duvarlarla karşılaşmayacağım) - ama ne acı!

Visual Studio, başlatılırken (bazı nedenlerden dolayı) URL'ye erişmeyi deneyecek:

/debugattach.aspx

.aspxDosyaları başka bir yere yönlendiren (veya yakalayan) bir yeniden yazma kuralınız varsa, bu hatayı alırsınız. Çözüm başlangıcına bu bölümü eklemektir web.config'ın <system.webServer>/<rewrite>/<rules>bölümünde:

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

Bu, bu belirli bir isteği yakalamanızı, hiçbir şey yapmamanızı ve en önemlisi, diğer kurallarınızın hiçbirinin çalışmaması için yürütmeyi durdurmanızı sağlar. Bu sağlam bir çözümdür, bu nedenle bunu üretim için yapılandırma dosyanızda saklamaktan çekinmeyin.

Başkalarının yararı için, benim durumumda uygulama havuzunu bir ağ kaynağı paylaşımına erişmek için Windows kimlik bilgilerimi kullanacak şekilde yapılandırmıştım. Çözümün hata ayıklamasından bu yana, Windows şifremi sıfırladım. Uygulama havuzunda ve bada bing'de depolanan şifre değiştirildi.

ApplicationPool Identity özel bir hesap olarak ayarlanmışsa ve bilgisayarın parolası değiştirilmişse, parolanızı güncellemeniz gerekir

Senaryom için, web.config'deki httpErrors bölümünde şu şekilde ayarlanan değişiklikler oldu:

<httpErrors mode="Custom"> 

"Web sunucusunda hata ayıklama başlatılamıyor" sorununa neden oldu. Bunu önceki "DetailedLocalOnly" değerine döndürmek sorunu çözdü. Biraz daha derine inerek, buna neden olan şeyin aslında sadece 401 hata ayarı olduğunu keşfettim:

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

401 hata satırını yorumlamak sorunu da çözdü, bununla devam ettim çünkü daha sonra özel hata işlemeyi sürdürebilir ve hata ayıklamaya başlayabilirim.

Hala bunun neden olduğu hakkında hiçbir fikrim yok.

Lütfen uygulama havuzunu kontrol edin. durdurulursa. yeniden başlatın.

Bir DNN (Dot Net Nuke) modülünde hata ayıklamaya çalışırken aynı sorunu yaşadım. Derleme debug = "true" olması gerektiği ortaya çıktı:

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

web.config dosyanızda. Varsayılan olarak DNN'de yanlıştır. Buradaki orijinal kaynak: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Yeniden yazma modülünü uyguladıktan sonra tam olarak aynı sorunu yaşıyorum.

Yeniden yazma girişlerini web.config dosyamdan kaldırırsam, hata ayıklama mükemmel şekilde çalışır.

Bunu aşmak için, hata ayıklama sırasında yeniden yazma etiketlerini şöyle yorumluyorum ...

<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>

Daha sonra hata ayıkladıktan sonra yorumları kaldırırım.

Visual Studio 2010'da bir hata olmalı.

IIS'de Uygulama havuzu durdurulduğundan beri aynı hatayı aldım. Uygulama Havuzunu başlattıktan sonra sorun çözüldü.

İşte not ettiğiniz hatayı temizlemek için yaptığım şey. Dosya sistemi içindeki uygulamanın web klasörünü bulun, Özellikler => Güvenlik'e gidin, Gelişmiş düğmesine tıklayın, ardından Sahip sekmesine tıklayın, Düzenle düğmesine tıklayın ve klasörün sahibini (doğru izinlerle) değiştirin ve " Yeniden Ayarla alt kapsayıcılarda ve nesnelerde sahip "onay kutusu. " Uygula " yı tıklayın ve sonra iş başındaydım (hata ayıklayabiliyordum).

Umarım bu başka biri için çalışır.

Sonunda bunu sahip olan tek çözümüm için bunu düzelttim. Çözümdeki projelerden ikisi IIS'de site olarak belirlendi. Hem proje hem de VIOLA için Kimlik Doğrulama altında ASP.Net Kimliğine Bürünmeyi etkinleştirdim ve etkinleştirdim! SONUNDA, artık bu sinir bozucu hataya son!

VS 2012'de aynı hata mesajını alıyordum, ancak Yönetici olarak çalışmıyordum. Uygulamayı yönetici olarak çalıştırdığımda, farklı ve biraz daha faydalı bir mesaj aldım (bunu çözebildim). HTH

Uygulama Havuzu yeniden başlatmada sorun yaşıyorsa veya yalnızca yeniden başlatmak istemiyorsa, Windows'un ASP.NET v4.0 veya başka bir Uygulama Havuzunda son güncellemeyi yapıp yapmadığını doğrulayın. Benim durumumda olan budur. Bilgisayarımı yeniden başlattım, ardından ASP.NET v4.0 Uygulama Havuzu'nu yeniden başlattım ve her şey yeniden çalışıyordu!

Dan,

Aaron'un önerilerine ek olarak aşağıdakileri deneyin

• IIS web sitenizde entegre Windows kimlik doğrulamasının seçili olup olmadığını kontrol edin
• IIS yerine Cassini kullanarak hata ayıklayabilir misiniz?

Tüm IIS Windows özelliklerini açtığınızda Windows 10 ile aynı sorunu yaşadım. Windows 8.1'e geçildi ve tekrar sorun yaşandı. Kök, " http: //MySite.local " web sitesi adındaydı (işletim sistemi sürümüyle ilgili değil).

Ve çözüm basit

• Hosts dosyasını içinde düzenle %SystemRoot%\System32\drivers\etc\

• İp bağlama ile satır ekleyin: 127.0.0.1 MySite.local

Bugün bu hatayı, IIS'nin isteklerle dolmasına neden olan çok sayıda kez geri gönderen koddaki bir kusur nedeniyle ortaya çıktım. Bu aslında IIS'yi kilitledi ve bu yüzden hata ayıklamaya çalıştığımda, hata ayıklayıcıyı başlatmaya çalışırken 'zaman aşımına uğradı'. Birkaç dakika süren IIS'yi yeniden başlattım ve sorunu çözdüm.

Bu hatanın daha az genel olmasını diliyorum, bunu üretmenin birkaç farklı yolu var gibi görünüyor.

Windows 8.1'de Visual Studio 2012 ve 2013'te aynı sorunu yaşadım. Benim için düzeltme, 'Windows özelliklerini aç veya kapat' seçeneğini kullanarak IIS'ye Windows Kimlik Doğrulaması eklemekti.

Sitenizin Uygulama Havuzunun doğru çerçeve sürümünü kullandığından emin olun . ASP.Net 2005 sitesinde "Hata ayıklama başlatılamıyor" hatasını aldım. Windows 7'de (.Net Framework 4 kullandığına inandığım) DefaultAppPool'u yanlış kullanıyordu. .Net Framework 2'ye dayalı yeni bir Uygulama Havuzu oluşturdum ve bunu sorunlu web sitesine atadım. Bundan sonra hata ayıklama iyi çalıştı.

IIS'deki web sitenizin durdurulmadığını kontrol edin.

Web sitemi çalıştırdım düzelttim. : D

Bu sorunu yaşadım ve sonunda ASP.net'in IIS'ye düzgün şekilde kaydedilmediğini fark ettim. Bu, IIS sunucusu Visual Studio'dan önce yüklendiğinde gerçekleşebilir. Bu sorunu çözmek için şu komutu kullanın -i aspnet_regiis bulunabilir ayrıntılı bilgi bağlantısını

aynı sorunu yaşadı. IIS'de SSL sertifikanız varsa ve Visual Studio'dan hata ayıklamaya çalışıyorsanız, uygulamanızı IIS'de sertifikayı yoksayacak şekilde ayarlamanız gerekir.

Aynı sorunu yaşadım ve bunun nedeninin Web.configbitiş etiketinden sonra yanlışlıkla bir karakter yazmamdan kaynaklandığını gördüm . Benim Web.configsonunda bu hakkı benziyordu: </section>h. "H", kapanış etiketinden sonra fazladan bir karakterdi.

iğneyi şu şekilde kaldırın: web.config içinde targetFramework = "4.0" veya AppPool'u uygun çerçeve sürümüne değiştirin.

IIS UrlScan Uzantısını kaldırmak sorunu benim için çözdü.

Aynı sorunla karşılaştım ama IIS yerine Visual Studio'nun kendi web geliştirme sunucusundaydı. Etrafta proje özellikleri, Sunucu ayarlarını tüm kullanıcılara uygula (proje dosyasında sakla.) Altındaki Web sekmesindeki seçeneğin işaretini kaldırmaktır. birinin değerli zamanını kurtaracak.

Ben de aynı sorunu yaşadım. Yukarıdaki cevapların hepsi benim için işe yaramadı. Çözüm, bin ve obj klasörünü manuel olarak silmekti.

Bu sorunu da buldum ama @Kirk'in açıkladığı ve URL'nin yeniden yazılmasına çok benziyordu.

Benim durumumda birisi bir MVC projesi için web.config dosyasındaki bu değişikliği kontrol etti:

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

Web sunucusunda .aspx dosya uzantılarına izin verilmediğinden, /debugattach.aspxURL reddedildi ve hata ayıklayıcının çalışması engellendi. Bu yapılandırmayı kaldırdıktan sonra tekrar çalıştı.

Visual Studio'da uygulama oluşturduğumda ve ardından özelliklerde yerel IIS ile kullanmak için sanal dizin oluşturduğumda aynı sorunu yaşadım. Birisi bu hatayı alıyorsa, bunun nedeni VS'nin yanlış AppPool altında, yani AppPool altında ihtiyaçlarınıza uymayan uygulama oluşturmasıdır.
Bu durumda, IIS Yöneticisi'ne gidin, Uygulama'yı seçin, Temel ayarlara gidin ve Uygulama için AppPool'u değiştirin ve gitmeniz iyi olur.

Geçenlerde aynı hatayı aldım ve benim durumumda yinelenen MIME türleri olduğu ortaya çıktı. Yakın zamanda listede başlangıçta görünmeyen iki tane ekledim. IIS bunları eklememe izin verdi ve yalnızca tanılama sürecimin bir parçası olarak site için MIME türlerini tekrar kontrol etmeye karar verdiğimde IIS'de de bir hata aldım. Web.config dosyasında kopyalara başvurdu. Web.config dosyasına geri döndüğümde, yeni eklenen iki MIME türünü içeren yeni bir bölümün eklendiğini fark ettim. O bölümü sildiniz ve hayat yine güzel! Bunun, sorunu diğer önerilerden herhangi biriyle çözmeyi başaramayanlara yardımcı olabileceğini umuyoruz.