リモートデバッグを使用したい。デバッグするプログラムはマシンbで実行されます。 Visual Studioはマシンaで実行されます。
マシンbには、次のファイルを含むフォルダーがあります。
一部のファイルが欠落していると思われる場合、それらが通常どこにあるのかを説明してもらえますか
次のステップで、msvsmon.exe
とマシンb上の私のプログラム。マシンaで、Visual Studio 2008とプログラムを作成したソリューションを開始しました。次に、「デバッグ-プロセスにアタッチ」を選択します。 「リモートトランスポート(認証なしのネイティブのみ)」を選択しました。正しいIPを修飾子として使用し、適切なプロセス(program.exe)を使用しました。しばらくすると、ポップアップウィンドウで次のメッセージが表示されました。
Program.exeの0x7c812a7bで処理されない例外:0xE0434F4D:0xe0434f4d
続行または中断できます。続行すると、例外が何度も何度も発生します。そこでブレークを押して、次のメッセージが表示されました。
呼び出しスタックフレームにシンボルはロードされません。ソースコードを表示できません。
アセンブリで生成された.PDBファイルをリモートマシンの同じフォルダに必ずコピーしてください。これにより、デバッガーはデバッグシンボルを取得できます。
_NT_SYMBOL_PATH
という環境変数をリモートマシンに設定しますリモートデバッガーは、開発マシンでシンボルを検索します。ビルドごとにコピーする必要はありません。
MSビデオ こちら をご覧ください。
8〜9分の視聴を開始します。開発マシンのドライブ共有からシンボルをロードするためのリモートデバッガーのセットアップ方法を説明します。
幸運を!
リモートプロセスをアタッチした後
。PDBファイルを同じディレクトリに配置デバッグされたコードが存在しない場合、.NETでのリモートデバッグは機能しません。
VSがまだデバッグ用のソースを見つけられない場合、デバッグされたコードとVSプロジェクトソースは同じバージョンではないです。ソリューションは、プロジェクトの再構築と再展開です。
0xE0434F4Dは、CLR(つまり、マネージコード)の例外です。認証を使用してリモートデバッグを実行し、マネージコードのデバッグを選択する必要があります。または、いくつかのデバッガー拡張機能を使用して、管理された例外情報を抽出することもできますが、もう少し面倒です。
参照:
1800情報は正しいです。マネージコードをデバッグするには、Windows認証を使用してリモートデバッグを行う必要があります。そうしないと、マネージアセンブリのシンボルを読み込むことができません。これを認証で動作させることは、とりわけ同じパスワードを持つ両方のマシンのローカルアカウントを必要とするため、かなり注意が必要です。この質問と全員の回答は、それを機能させるのに非常に役立ちます。
同じ問題がありました。 msdn forums で答えを見つけました。正しい答えをここにコピーして貼り付けます。
正しいバージョンのmsvsmon.exeを使用していることを確認してください!!!それだけです! C#アプリケーションのリモートデバッグ中に同じ問題が発生しました。サーバーはWindows Server 2008 64ビットを実行しているため、x64 msvsmon.exeを使用していましたが、アプリケーションはx86用に作成されていたため、この迷惑なエラーを取り除くにはx86バージョンのmsvsmon.exeを実行する必要がありました。他に何も必要ありませんでした。アプリケーションのターゲットアーキテクチャに対応するバージョンのmsvsmon.exeを実行するだけです^ _ ^
上記の答えは正しいものの、デバッグされているアセンブリを使用して構築されたPDBがリモートの場所にあり、ピックアップされていない場合に遭遇しました。 TFSまたはデバッグシンボルの発行をサポートする別のビルドメカニズムを使用している場合は、実行することをお勧めします。次に、Visual Studioの[オプション]> [デバッグ]> [シンボル]で、その場所を[シンボルサーバー]オプションに追加して、一致するシンボルが見つかったときにそれらのシンボルを読み込むことができます。
これにより、動的に呼び出されるアセンブリ(アセンブリでシンボルを公開するだけでは機能しなかったもの)であっても、実行している実行中のあらゆるものの近くでデバッグすることができました。この非常に便利な機能を利用してください!
また、カスタムビルド構成を使用しているときにこれに遭遇しました。 (デバッグの代わりにDEV)
これを修正するために、プロジェクトのプロパティ->ビルド->出力->詳細設定を変更し、出力->デバッグ情報の設定がfullまたはpdb-only。デフォルトのRelease構成は通常、noneに設定されます。
[プロジェクトのプロパティ]、[コンパイル]タブに移動し、ビルド出力パスをリモートマシンに設定することで、これを機能させることができました(例:\ myserver\myshare\myappdir
[デバッグ]タブで、[リモートマシンを使用する]をオンにし、myserverに設定します
Tools-> Options-> Debugging-> Symbolsに移動し、実行可能ファイルの.pdbファイルへのパスを追加します。ローカルマシン上のパスは正常に機能しました。
私はこの問題にぶつかりましたが、上記の解決策では解決しませんでした。私の場合、VS2010ソリューションには多くのプロジェクトが含まれていました。リモートでデバッグしようとしたプロジェクトは、VS2010ソリューションでスタートアッププロジェクトとして設定されていましたnot。
デバッグしようとしていたソリューション内のプロジェクトを右クリックして、Set as StartUp Project
その後、シンボルが適切にロードされ、ブレークポイントにヒットしました。
リモートデバッグ中にも同じ問題が発生しましたが、VS 2008では次の手順で解決されました。
ドキュメントによると、マネージド(Visual Studio 2012のリモートマシンでマネージドWindowsサービス(.net 4.5に対して構築)にアタッチしようとした)のシンボルはリモート上マシンである必要があります。
そのため、リモートマシン上でシンボルを保持し(リモートマシン上のアプリケーションのモジュール/アセンブリと一致することを確認)、それを共有し、ローカルシステムのシンボル設定を介して参照します(vsが実行されています)。
注:サービスとシンボルは、2k12 + .net 4.5 Windowsサービスで動作するのと同じディレクトリにある必要はありません。
詳細:
http://msdn.Microsoft.com/en-us/library/bt727f1t(v = vs.100).aspx
リンクからの抜粋:
シンボル(.pdb)ファイルを見つける
シンボルファイルには、コンパイルされた実行可能ファイルのデバッグ情報が含まれています。デバッグするアプリケーションのシンボルファイルは、アプリケーションの実行可能ファイルがコンパイルされたときに作成されたファイルでなければなりません。シンボルファイルは、デバッガーが見つけられる場所に配置する必要もあります。
•ネイティブアプリケーションのシンボルファイルは、Visual Studioホストコンピューターに配置する必要があります。
•管理対象アプリケーションのシンボルファイルは、リモートコンピューターに配置する必要があります。
混合(管理およびネイティブ)アプリケーションのシンボルファイルは、Visual Studioホストコンピューターとリモートコンピューターの両方に配置する必要があります。
よろしく!