Visual Studio 2015 RTM-デバッグが機能しない
VS 2015 RTM（他に何も）をインストールしましたが、既存のソリューションであろうと新しいソリューション（VS 2015で作成され、.Net Framework 4.6に対してコンパイルされたものであろうと）に関係なく、ソリューションをデバッグできません）、VSでブレークモードと呼ばれる新しいタブが開き、次のテキストが表示されます：アプリケーションはブレークモードですアプリはブレーク状態に入りましたが、選択したデバッグエンジンでサポートされているコードは実行されていません（例：ネイティブランタイムコードのみが実行されています）。 [デバッグ]-> [モジュール]ウィンドウをチェックすると：VS2015Test.vshost.exeシンボルが読み込まれません（[シンボルを読み込む]をクリックしても機能しません）VS2015Test.exeシンボルが読み込まれました
また、コンソールに出力を表示しません（次のコード行だけを持つコンソールアプリケーションです：
class Program
{
static void Main(string[] args)
{
Console.WriteLine("TEST");
Console.ReadKey();
}
}
VS 2015を再インストールして、コンピューターを再起動し、％temp％/ AppData/Microsoft/Visual Studio/14のすべてのファイルを削除し、VSを管理者モードで起動しようとしましたが、何も機能しないようです。
デバッグを機能させる1つのことは、このオプションです。ツール->オプション->デバッグ->マネージ互換モードを使用
^^しかし、それは古い/レガシーモードを使用する解決策にはなりません。
ところで：VS 2013でのデバッグは正常に機能しています。
任意の助けをいただければ幸いです。
私はVS2015でも同じ問題を抱えていました。提案どおりに設定をリセットしましたが、まだ問題がありました。
それを修正するために私がしなければならなかったことは、「管理互換性モードを使用する」と「ネイティブ互換性モードを使用する」をチェックすることでした。これら2つのうちどちらが必要かはわかりませんが、両方をチェックすると、ブレークモードの問題が発生しなくなりました。
最近、デバッグ設定に関連する非常に類似した問題がありました。
まず、すべての設定をリセットしようとしましたか？これは、プロジェクトに依存せず、すべてのアプリケーションデータを削除したということと関係があると思います。
ツール->設定のインポートとエクスポートWizard->すべての設定をリセット
心配する必要はありません。現在の設定を保存するオプションがあります。
次に、これが失敗した場合、イベントログを確認することをお勧めします。
ブレークモードに入ると、DE（デバッグエンジン）が IDebugExceptionEvent2 のようにVisual Studioに同期停止イベントを送信していることを示唆します。参照アセンブリ（.NETランタイムなど）の読み込みエラーや環境アクセス制限などの例外については、イベントログを確認します。
デバッガが実行中のアプリケーションを停止するように指示しているのは、それを見つけるための単なるケースです。
誰かを助けるためにこれを投稿すると思いました。クリーンなWin 10とVisual Studio 2015をインストールし、既存のソリューションをデバッグしようとしましたが、問題がありました。ここにリストされているいくつかのアドバイスや他の場所に従いましたが、どれも機能しませんでした。
デバッグを通常どおり動作させる方法は、メニューのすぐ下にあるソリューション構成を変更することでした。以前にリリースモードに設定し、これをデバッグに変更してから、クリーンアップ/再コンパイルし、ちょっと前に、デバッグは正常に動作し始めました。詳細については画像をご覧ください。
デバッグで動作するように私のソリューションが突然停止しました。デバッグ中にメッセージを受け取りました。 
[ウィンドウタイトル] Microsoft Visual Studio [主な説明] NettoProWin.exeのリリースビルドをデバッグしています。コンパイラ最適化を使用してリリースビルドでJust My Codeを使用すると、デバッグエクスペリエンスが低下します（たとえば、ブレークポイントにヒットしません）。 [デバッグの停止] [自分のコードのみを無効にして続行] [デバッグの継続] [デバッグの継続（再度尋ねない）]
デバッグを続けることにしましたが、それでも動作しませんでした。
解決策は簡単でした。プロジェクトのプロパティで必要です->ビルドセクションで->「Optimiz code」のチェックを外します 
プロセスにアタッチする前に「コードタイプ」を確認してください。たとえば、CoreCLRからv4。*に切り替える必要がありました。
Debugger.Launchを使用してWebアプリケーションをデバッグしようとすると、このような問題が発生しました。JITデバッガーの選択ウィンドウが表示されませんでした。コンソールアプリで問題なく起動するため、VSデバッグメカニズム自体には問題がないことはわかっていました。
最終的に同僚は、電球を始動させる「グローバルデバッガレジストリ設定」に言及しました。
数か月前にMicrosoftのDebugDiagを使用してIISクラッシュのトラブルシューティングを行っていましたが、IISクラッシュダンプをキャプチャするルールが登録されていました。 w3wpのデバッガー（IISワーカープロセス）。
DebugDiagでルールを削除するか、Debug Diagnostic Service（ "C：\ Program Files\DebugDiag\DbgSvc.exe"）を停止すると、Visual StudioのJITデバッグが再度有効になりました。
これが誰かを助けることを願っています。
アバストファイルシステムシールドを無効にすると、すべて正常に機能するようになりました。 avast-setting wheel =アクティブ保護-上部ボタンがオフ。
プロジェクトの公開にも同じことが必要です。本当の悪夢
ええと私はこのページの一番下に行きましたので、私のプロジェクトを引き裂き始めました。特定の問題の解決策を見つけました。
私の問題：スレッド化されたプロセス内でブレークポイントに到達できませんでした。特別なことは何もありません。コンソールアプリで新しいスレッドを開始するだけで、デバッガーはブレークポイントで停止していませんでした。スレッドが作成されていることに気付きましたが、.Net Framework外部呼び出し、特にThreadStart_Contextでハングアップしていました。 .Net Frameworkがハングアップして、ブレークポイントがヒットしなかった理由を説明しています。
問題：スタートアップコードを変更することでこれを解決できることがわかりました。何らかの理由で、Main（）を含むprogram.csファイルがあり、コンソールアプリに期待されるようにProgramクラス内にありました。 Main（）内では、このコードを介して別のクラスをインスタンス化していました。
new SecondClass();
これは通常正常に機能し、スレッドコールを使用する他のプロジェクトが多数あり、正常に動作します（まあ、しばらくデバッグしていなかったため、おそらくサービスパックが登場してこのリグレッションを引き起こしています）。
ソリューション： Main（）をSecondClassに移動し、 'new SecondClass（）'を介してSecondClassコンストラクターを呼び出す代わりに、SecondClassコンストラクターを標準の静的メソッドに更新してからMainから呼び出します。これらの変更を行った後、スレッドをもう一度デバッグすることができます。
お役に立てれば。
私の場合、
デバッグ構成マネージャーでプラットフォームをx86からx64に変更しました。それは私のために働いた。
Vs 2017のインストール後、ソリューションのデバッグ中に「Webkitは正常に機能しなくなりました。VisualStudioはアプリをこれ以上デバッグできません。」、これは続行できませんこの問題を解決するには、Tools-> Options-> Debugging-> Generalに進み、asp.netのjavascriptデバッグを無効にします
Visual Studio 2015で実行するsvcアプリケーションで同様の問題が発生しました。ソリューションは、ソリューションプラットフォームを「Any CPU」から「x86」に変更し、x86オプションが表示されない場合は「Configuration Manager」をクリックして、ターゲットプロジェクトとプラットフォームを変更するには、ドロップダウンを選択して「新規」をクリックし、ポップアップで「新しいプラットフォーム」の下のドロップダウンリストをクリックしてx86を選択し、変更を保存して再構築する必要があります（添付を参照してください- 
）
プラットフォームターゲットを「任意のCPU」から「x64」に変更しました。
で利用可能な設定：プロジェクトプロパティ->ビルド->一般： "プラットフォームターゲット"
VS 2015を使用しています。
私の場合、出力ウィンドウで、デバッガーを停止した例外がContextSwitchDeadlock例外であるというヒントを見つけました。これは、例外設定でデフォルトでチェックされています。この例外は通常、コンソールアプリケーションで60秒後に発生します。例外のチェックを外しただけで、すべて正常に機能しました。
ソリューションエクスプローラー-> Web->プロパティから
[ビルド]タブ-> [構成]コンボボックスを選択します。
構成を「リリース」から「アクティブ（デバッグ）」に変更するだけです
- デバッグを停止します。
- Csproj.userファイルを編集します
- 以下に記述された検索セクション：
<SilverlightDebugging> True </ SilverlightDebugging>
- 値を「False」に変更します
- Visual Studioでプロジェクトをアンロードして再ロードします。
- Visual Studioを閉じる必要がある場合がありました。
プロジェクトの設定-> Webに移動し、[編集して続行を有効にする]チェックボックスをオンにする必要があることがわかりました。そもそもなぜそれがチェックされていなかったのかは言えませんが、これで解決しました。 
.vsフォルダーの削除、IISExpressフォルダー名の変更、プロパティのさまざまな設定の更新など、他のすべてのオプションを試した後、この問題が発生しました。ただし、機能したのは、IISExpress 10.0をアンインストールし、Windows機能からIIS関連機能をすべて有効にして再インストールすることでした。これが誰かを助けることを願っています。
これと同じ問題がありました。私の場合、デバッグしようとしたdllはGACにインストールされていました。ターゲットアセンブリ内のオブジェクトを参照していないときにデバッグブレークポイントがヒットしたが、アセンブリを参照したときにヒットしなかった場合、これが当てはまる場合があります。
私の場合、それはプロジェクトによるものでしたターゲットプラットフォームは異なっていました。
考慮する：ProjectA（Entry）-> ProjectB
ProjectAのプロパティのプラットフォームはx64に設定されていました。そしてProjectBのプラットフォームは 'AnyCPU'でした。
ProjectBのターゲットプラットフォームをx64に設定すると、この問題は修正されました。
注：それは、ターゲットプラットフォームが同期していなければならないということだけですx64または 'Any CPU'
私はこの問題を抱えていましたが、ここでの（無数の）投稿はどれも役に立ちませんでした。ほとんどの人は、設定、またはオプション、デバッグモードの有効化などを指摘します。これはすべて、すでに用意されていました（昨日は正常に機能していたので、それではないことはわかっていました）。
私にとってそれは参照の問題であることが判明し、含まれていたDLLの組み合わせが原因でした。私は問題が何であったかを正確に言うことはできませんが、別のプロジェクトから基本クラスを拡張したいくつかのクラス、それ自体が別のインターフェイスから拡張された実装されたインターフェイスなどがあります。
酸性テストは、デバッグに失敗したプロジェクトと同じプロジェクト内に新しいクラス（私の場合は単体テスト）を作成し、空のメソッドを作成してブレークポイントを設定することでした。これは機能し、私の設定/オプション/などが良好だったことをさらに検証しました。次に、デバッグに失敗したメソッドの本文をコピーし、新しいメソッドも失敗し始めたことを確認しました。
最終的に、すべての参照を削除し、メソッド内のすべての行をコメント化しました。犯人が見つかるまで、それらを1つずつ追加し、各ステップで[デバッグ]をチェックします。私は明らかにどこかで不正な参照を持っていました...
友人も同じ問題を抱えていました。VS2015ではデバッグできませんでしたが、VS2013では問題ありませんでした。 （プロジェクトは.Net v4.0にあります）
「Managed（v4.5、v4.0）」ではなく「Managed（v3.5、v3.0、v2.0）」に設定されたのは、Debug/Attach to Processの「Code Type」オプションであることがわかりました。 ）」