25

私が見つけたすべてのドキュメント（参照1から5）は、共有UNCパスを使用してシンボルサーバーをセットアップし、ローカルデバッガーインスタンスで正しい設定を利用できるようにすることについて説明しています（_NT_SYMBOL_PATHまたはVisual StudioIDEデバッグ設定） ）。

Microsoftは、パブリックシンボルストア用にhttp経由で利用できるシンボルサーバー（リファレンス6）を提供しています。

自分のコード用に、UNCファイル共有ではなくhttpトランスポートを介してアクセスできるシンボルサーバーを作成したいと思います。Mozillaの人々はそうしているように見えますが（参照7）、それはもはや機能していません。

私がこれまでに見つけたよりも、このタスクを実行するために利用できるより良いリファレンスはありますか？

参考文献

  1. https://msdn.microsoft.com/en-us/library/b8ttk8zy(v=vs.80).aspx
  2. http://msdn.microsoft.com/en-us/library/ms680693(v=vs.85).aspx
  3. http://stackhash.com/blog/post/Setting-up-a-Symbol-Server.aspx
  4. http://entland.homelinux.com/blog/2006/07/06/… _
  5. http://msdn.microsoft.com/en-us/windows/hardware/gg462988
  6. http://support.microsoft.com/kb/311503
  7. http://developer.mozilla.org/en/Using_the_Mozilla_symbol_server
4

4 に答える 4

16

答えは非常に単純だと思います。「何らかの http パスを介してディレクトリを共有するだけです。」「Creating Your Own Symbol Server」に関する Chad Austin のエントリによると、これは問題なく機能します。

symstore.exeつまり、シンボルの格納に使用されるディレクトリは、 http://symbols.example.com/public_symbols/として提供されると、Windows デバッグ ツールのシンボル サーバー ターゲットとして使用できます。

于 2011-03-30T16:02:09.047 に答える
15

複数のユーザーが同じシンボル ストアに対して直接 Symstore.exe を使用する場合は注意してください。このテーマに関する Microsoft のホワイト ペーパーでは、単純に共有を作成し、Windows 用デバッグ ツールの一部として提供される SYMSTORE.EXE プログラムを介して全員が更新するように聞こえます。ホワイト ペーパーでは、ビルドごとにこれを実行するようにアドバイスされています。

また、1 人のユーザーの場合や、チームのシンボル サーバーを更新している 1 人のユーザーを介してすべての更新をファネリングする場合に最適です。

残念ながら、一部のホワイト ペーパーの下部にある「詳細」には、symstore.exe を実行している 1 人のユーザーのみが、コンテンツを壊さずに共有シンボル サーバーを同時に更新できると書かれています。

(例: http://msdn.microsoft.com/en-us/library/ms681417(VS.85).aspxで、Microsoft は次のように述べています。シンボル ストアの "管理者" に指定され、すべての追加および削除トランザクションに責任を負います。")

そのため、シンボル ストアへの更新をシリアル化する固有のメカニズムはありません。シンボル ストアを複数同時に更新しようとすると、シンボル ストアやそのインデックスが破損する可能性があるようです。

1 か所で 1 人の人員による調整に依存しているすべてのタイム ゾーンで、数千人規模の国際企業全体を構築することはできません。

これらのホワイト ペーパーに基づいて、私は 2009 年 3 月に Microsoft にこの問題を提起しました。これが問題になる可能性があることを確認した人。その議論の後、Windows Debugging Tools SDK DbgEng.DLL SymbolSrvStoreFile() API 呼び出しを直接介して更新をシリアル化するシンボル更新サービスを実装することを選択したため、シンボルの同じ領域に対して同時に 2 つの更新が同時に行われる可能性はありません。 . ユーザーには、シンボル ストアを直接更新する代わりに、サービスを介してシンボルをキューに入れるビルド アクションがあります。次に、サービスは更新をシリアル化し、真の同時更新試行が発生しないようにします。

当時、SymSrvStoreFile の使用に関する限られたドキュメントはあまり明確ではありませんでした。私はそれを機能させました。それ以来改善されていることを願っています。そうでない場合、最も重大な問題は、_NT_SYMBOL_PATH のような形式で入力パスを指定する必要があることです。たとえば、入力パスとして「C:\Data\MyProject\bin」を使用する代わりに、「srv*C:\Data\MyProject\bin」を指定します。

私たちのサービスは、データベースを介して更新も記録するようになりました。データベースは、シンボル ストアのバックアップとして機能し (破損して再構築が必要な場合に備えて)、レポート ポイントを作成して、管理者とサポート担当者が実際にシンボルを保存している人と保存していない人を把握できるようにします。利害関係者に自動電子メールで送信される毎週の「シンボル チェックイン」レポートを生成します。

于 2012-03-23T13:26:02.110 に答える
7

HTTP を介して提供されるシンボル サーバーは、UNC ファイル パスを介して提供されるシンボル サーバーと同じ構造を持っているため、最も簡単な方法は、symstore.exe を使用してファイルをどこかのフォルダーに保存し、単純な HTTP サーバーを使用することです。そのフォルダーを HTTP 経由で公開します (python -m SimpleHTTPServerシンボル dir で実行しても機能します)。

ちょっとした問題として、シンボル ファイルが存在しない場合、HTTP サーバーは 404 エラー コードを返す必要があります (少なくとも Visual Studio 2013 でテスト済み)。不足しているファイルに対して 403 を返す HTTP サーバーが原因で、最初の失敗した要求の後に Visual Studio が要求の作成を停止するという問題に遭遇しました。

symstore.exe は、多数の補助ファイルとフォルダー (000Admin/フォルダーrefs.ptrとfiles.ptrファイル) を作成します。これらはいずれも、シンボル サーバーが機能するために必要なものではありません。

symstore.exe を使用せずにシンボル ストアを作成する場合は、次の構造のファイルをアップロードできます。

BinaryName.pdb/$BUILD_ID/BinaryName.pdb BinaryName.exe/$LINK_ID/BinaryName.exe

はPDBBUILD_IDファイルと実行可能ファイルに埋め込まれた GUID であり、実行可能LINK_IDファイルのビルド タイムスタンプとファイル サイズの組み合わせです。これらは、breakpad ライブラリから dump_syms.exe ツールの出力を読み取ることで取得できます。http://www.chromium.org/developers/decoding-crash-dumpsを参照してください

于 2014-05-12T16:55:10.413 に答える
5

私たちの (Mozilla の) シンボル サーバーは問題なく動作します。特に複雑なことはしていません。PDB ファイルを適切なディレクトリ構造に配置し (そのためのスクリプトがありますが、symstore.exe を使用することもできます)、Apache 経由で提供するだけです。Microsoft のツールはファイル名/GUID の大文字と小文字に一貫性がないため、大文字と小文字を区別せずにファイルにアクセスできるようにするための書き換えルールだけが特別だと思います。

于 2013-06-14T15:04:15.153 に答える