Webサーバーでデバッグを開始できません。 VS 2010、II7、Win 7 x64のデバッグASP.NETを開始できませんでした
Windows 7 x64上でVisual Studio 2010（管理者として）IIS 7を実行しています。 ASP.NET WebサイトをIIS 7で正常にデバッグすることなく実行できますが、F5を押してデバッグすると、次のようになります。
Webサーバーでデバッグを開始できません。 ASP.NETデバッグを開始できませんでした。デバッグせずにプロジェクトを開始すると、より多くの情報が利用できる場合があります。
残念ながら、ヘルプのリンクはあまり役に立たず、たくさんの大きなツリーにつながっています。
以下を確認しました。
セキュリティ要件—以前に特別なことをしなければならなかったことを思い出しません。 IIS7のワーカープロセスはw3wp.exeです。 ASPNETまたはNETWORK SERVICEとして実行している場合、デバッグするには管理者権限が必要だと言われています。ここで何かを変更する必要があるかどうかを確認するにはどうすればよいですか？
Webサイトのプロパティページ>開始オプション>デバッガー> ASP.NETがチェックされます。 [カスタムサーバーを使用]がサイトのURLに設定されます（デバッグなしで正常に機能します）。
web.configでデバッグが有効になっています。アプリケーションはASP.NET 3.5を使用しています（最終的に4.0に移行したいのですが、対処するための移行が必要です）。
アプリケーションプール：.NET AppPoolの分類（DefaultAppPoolも試されました）。
次に確認できるアイデアはありますか？
確かに、IIS、VSをインストールし、Webサイトを作成し、テストを開始するのはそれほど難しくないはずです。
前もって感謝します。
原因はIIS rl Rewriteモジュールであったことが判明しました。 Default.aspx（Webサイトの開始ページとして設定された）への呼び出しをサイトのルートにリダイレクトするルールを定義していたため、正規のホームURL。しかし、どうやらVSにはこれに問題があり、混乱していたようです。 Helicon ISAPI_Rewriteを使用している場合、この問題は発生しなかったため、確認することさえありませんでした。
私はまったく新しいWebサイトをゼロから作成し、プロジェクト/ファイルを少しずつソリューションに移植し、これが見つかるまでweb.configを再構築しました！まあ、少なくとも今は.NET 4.0を使用して少しきれいなサイトを作成しています（これまでのところ、私は壁にぶつからないことを願っています）。
IISに移動して、使用しているアプリケーションプールが開始されていることを確認してください。多くの場合、アプリプールをシャットダウンするエラーが生成されます。右クリックして開始するだけで、準備完了です。
Visual Studioは、起動時に（何らかの理由で）URLにアクセスしようとします。
/debugattach.aspx
たとえば、.aspxファイルをリダイレクト（またはキャッチ）する書き換えルールがある場合、このエラーが発生します。解決策は、このセクションをweb.configの<system.webServer>/<rewrite>/<rules>セクションの先頭に追加することです。
<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
<match url="^debugattach\.aspx" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="None" />
</rule>
これにより、この特定の1つのリクエストを確実にキャッチし、nothingを実行します。そして、最も重要なこととして、実行を停止して、他のルールが実行されないようにします。これは堅牢なソリューションであるため、本番環境の構成ファイルに自由に保管してください。
他の人のために、私の場合、Windowsリソースを使用してネットワークリソース共有にアクセスするようにアプリケーションプールを構成しました。ソリューションのデバッグを最後に行ってから、Windowsパスワードをリセットしました。アプリプールとbada bingに保存されているパスワードを変更しました。
ApplicationPool Identityがカスタムアカウントに設定され、コンピューターのパスワードが変更された場合、パスワードを更新する必要があります
私のシナリオでは、web.configのhttpErrorsセクションが次のように変更されました。
<httpErrors mode="Custom">
「Webサーバーでデバッグを開始できません」問題が発生しました。 「DetailedLocalOnly」の以前の値に戻すと、問題が修正されました。少し掘り下げてみると、実際には401エラー設定が原因であることがわかりました。
<httpErrors mode="Custom">
<error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom">
401エラー行をコメントアウトすると、問題も修正されました。カスタムエラー処理を維持し、デバッグを開始できるので、それを使用しました。
なぜこれが起こっているのか、まだわかりません。
アプリケーションプールを確認してください。停止している場合。再起動してください。
DNN（Dot Net Nuke）モジュールをデバッグしようとしても同じ問題がありました。コンパイルdebug = "true"が必要であることが判明しました。
<compilation debug="true" strict="false" targetFramework="4.0">
web.configで。デフォルトでは、DNNではfalseです。ここに元のソース： http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts
書き換えモジュールを実装した後も、まったく同じ問題があります。
Web.configファイルから書き換えエントリを削除すると、デバッグは完全に機能します。
これを回避するには、デバッグ中に次のように書き換えタグをコメントアウトするだけです...
<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>
次に、デバッグ後にコメントを削除します。
Visual Studio 2010のバグである必要があります。
IISでアプリケーションプールが停止されたため、同じエラーが発生しました。アプリプールを開始した後、問題は解決されました。
ここに、あなたが指摘したエラーをクリアするためにしたことを示します。ファイルシステム内でアプリのWebフォルダーを見つけ、プロパティ=>セキュリティに移動します詳細ボタンをクリックしてから所有者タブをクリックし、クリックします編集ボタンをクリックし、フォルダの所有者を変更して（適切な権限を持つ）、「サブコンテナとオブジェクトの所有者を置き換える」チェックボックスをオンにしました。 「Apply」をクリックすると、ビジネスを開始しました（デバッグ可能）。
これが他の人に役立つことを願っています。
ついに、これを抱えていた単一のソリューションでこれを修正しました。ソリューションの2つのプロジェクトは、IISのサイトとして設定されました。私は、両方のプロジェクトとVIOLAの認証でASP.Net偽装を有効にしました！最後に、この迷惑なエラーはもうありません！
アプリプールの再起動に問題がある場合、または単に再起動したくない場合は、ASP.NET v4.0または他のアプリプールでウィンドウが最近更新されたかどうかを確認します。それが私の場合に起こったことです。コンピューターを再起動し、ASP.NET v4.0アプリプールを再起動しただけで、すべてが再び機能しました。
VS 2012でも同じエラーメッセージが表示されましたが、管理者として実行されていませんでした。管理者としてアプリを実行したとき、私は別のわずかに役立つメッセージを受け取りました（これは理解できました）。 HTH
ダン、
アーロンの提案に加えて、以下を試してください
- IIS Webサイトで統合Windows認証が選択されていることを確認します
- IISの代わりにCassiniを使用してデバッグできますか？
すべてのIIS windows機能をオンにしたときに、Windows 10で同じ問題が発生しました。 Windows 8.1に切り替えて、再び問題が発生しました。ルートはWebサイト名「 http：//MySite.local 」にありました（OSバージョンに関係ありません）。
そして解決策は簡単です
%SystemRoot%\System32\drivers\etc\のhostsファイルを編集しますIPバインディングで行を追加：
127.0.0.1 MySite.local
IIS上のWebサイトが停止していないかどうかを確認してください。
Webサイトを実行できるように修正しました。 ：D
サイトのアプリケーションプールが正しいフレームワークバージョンを使用していることを確認してください。 ASP.Net 2005サイトで「デバッグを開始できません」というエラーが表示されました。 Windows 7でDefaultAppPoolを誤って使用していました（これは.Net Framework 4を使用していたと思われます）。 .Net Framework 2に基づいて新しいアプリケーションプールを作成し、問題のWebサイトに割り当てました。その後、デバッグは正常に機能しました。
同じ問題があった。 SSL証明書がIISにインストールされており、Visual Studioからデバッグしようとしている場合は、証明書を無視するようにIISにアプリケーションを設定する必要があります。
この問題が発生し、最終的に、I ASP.netがIISに適切に登録されていないことに気付きました。これは、Visual Studioの前にIISサーバーがインストールされている場合に発生する可能性があります。この問題を修正するには、コマンドaspnet_regiis -iを使用します。詳細は link
Windows 8.1上のVisual Studio 2012および2013でも同じ問題が発生しました。私にとっての修正は、「Windows機能をオンまたはオフにする」を使用してIISにWindows認証を追加することでした
私は同じ問題を抱えていて、Web.configの終了タグの後に誤って文字を入力したことが原因であることがわかりました。私のWeb.configは最後に</section>hのように見えました。 「h」は、終了タグの後の余分な文字です。
今日、このエラーが発生したのは、コードに欠陥があり、IISに大量のリクエストが大量にポストバックされていたためです。これは本質的にIISをロックアップしたため、デバッグしようとしたときに、デバッガーを開始しようとして 'タイムアウト'しました。 IISを再起動するだけで数分かかり、問題は解決しました。
このエラーがあまり一般的ではないことを願っています。エラーを生成する方法はいくつかあるようです。
Visual Studioでアプリケーションを作成し、ローカルIISで使用する仮想ディレクトリをプロパティで作成したときに同じ問題が発生しました。誰かがこのエラーを抱えているのは、VSが間違ったAppPoolの下、つまりニーズに合わないAppPoolの下にアプリケーションを作成するためです。
この場合、IIS Managerに移動し、[アプリ]を選択して[基本設定]に移動し、AppのAppPoolを変更してください。
IIS UrlScan Extensionをアンインストールすると、問題が解決しました。
私もこの問題を見つけましたが、@ Kirkが説明したこととURLの書き換えに最も似ていました。
私の場合、誰かがこの変更をMVCプロジェクトのweb.configファイルにチェックインしました。
<system.webServer>
<security>
<requestFiltering>
<fileExtensions>
<add fileExtension=".aspx" allowed="false" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
.aspxファイル拡張子はWebサーバーで許可されていなかったため、/debugattach.aspx URLが拒否され、デバッガーの実行が妨げられました。この構成を削除すると、再び機能しました。
最近、同じエラーが発生しましたが、私の場合、MIMEタイプが重複していることがわかりました。最初にリストに表示されなかった2つを最近追加しました。 IISを追加します。診断プロセスの一環としてサイトのMIMEタイプを再度確認することにしたときのみ、IISでもエラーが発生しました。 web.configで重複を参照しました。 web.configファイルに戻ると、最近追加された2つのMIMEタイプを含む新しいセクションが追加されていることに気付きました。そのセクションを削除し、人生は再び良いです！これが、他の提案で問題を解決できなかった他の人の助けになることを願っています。
私は同じ問題に直面していましたが、IISではなくVisual Studio独自のWeb開発サーバーにありました。回避するには、プロジェクトプロパティの下のWebタブでオプションをオフにし、すべてのユーザーにサーバー設定を適用します（プロジェクトファイルに保存します）。貴重な時間を節約できます。
同じ問題がありました。上記のすべての答えは私にとってうまくいきませんでした。解決策は、binおよびobjフォルダーを手動で削除することでした。
このような刺し傷を削除：web.configのtargetFramework = "4.0"またはAppPoolを適切なフレームワークバージョンに変更します。