4

数日前、私は職場でこの問題に直面し、Microsoft に行くよりもシナリオからより多くのデータを作成する方法があるのではないかと考えていました。このようなケースは数多くあり、Windows 開発者として、ほとんどの情報を取得するための最良/最適な方法がそのようなケースであることを探りたいと思いました。状況を説明します：

  1. Office アプリケーションで、特定の設定 (cmyk カラー スペースを含む) で印刷すると、説明が不適切なダイアログ ボックス エラーが表示されます。「ファイル %s は、他のアプリケーションによってロックされているため、開けませんでした」. ファイル名もイベント ビューアも与えません。印刷は中止されます。

  2. を使用すると、Office アプリ、スプーラー、splwow64.exe などの関連するプロセスによってprocmonAPI が呼び出されると、いくつかのファイルで「ファイル ロック エラー」が見つかります(はい、64 ビット システムであり、アプリは 32​​ ビットです)。CreatefileMapping

  3. splwow64 が関与していない場合、問題はありません。64 ビット OS で 64 ビット アプリを使用することを意味します。

そのような状況でより多くの情報を得るためにどのツールが役立つか知りたいです。これには、必要に応じて、windbg およびデバッグ アセンブリでの MS シンボルの使用が含まれます。基本的に、ロックされているファイル名が必要です。これは %s として表示され、問題のルートです。

4

1 に答える 1

5

ソースコードもシンボルもなしにデバッグするのは困難です。取るべきアプローチは、何を観察できるか、どのような仮定を立てられるかによって大きく異なります。以下は、あなたの状況にとって妥当に聞こえます。

64 ビットのファイル アクセスを 32 ビット バージョンと比較します。

64ビット版でも動作するので、ファイルアクセスの違いはどうなのか見てみましょう。Process Monitor ログを CSV にエクスポートし、ファイル アクセスを分析するツールを作成できます。あなたの分析ツールはおそらく

  • オフセットが異なる複数のファイル読み取りアクセスを、ファイル全体に対する単一のファイル アクセスにまとめます。
  • 順序はそれほど重要ではないように思われるため、読み取り順序は無視してください。
  • 最初は DLL を無視する

たぶん、Excel自体でそれを行うことさえできます。

ファイル アクセス コールのキャプチャ

まず、Process Monitor を使用することは、すでに良いアプローチだと思います。アプリケーションについて何も知らなくても、アプリケーションが何をしているかを知ることができるので、それが私の最初の選択です。

もちろん、問題のファイルのリストを絞り込むことは困難です。必要に応じて、たとえばバッチ ファイルを使用してそれらすべてを確認し、ファイルを開いたアプリケーションを見つけるのに役立つコマンド ライン ツールを見つける必要があります。この場合、SysInternals Handleを見てください。これはコマンド ライン ユーティリティであり、ファイル名を付けることができます。基本的に、これは Process Explorer のコマンド ライン バージョンです (以下を参照)。

ファイルの読み取りとファイルの書き込みは通常、API 呼び出しを介して行われるため、API モニターも別のオプションです。疑わしいすべてのファイル アクセス メソッド (ReadFile、ReadFileEx、LockFile、LockFileEx、WriteFile、WriteFileEx、...) をフィルター処理します。

これは、WinDbg でブレークポイントを設定することによっても実現できますが、ブレークポイントを頻繁にヒットする可能性があるため、それらの処理にはおそらく自動化が必要です。コマンドにはコマンド文字列を指定できますbp。

幸運になる

フォーマット文字列の引数として使用することを意図したファイル名が%sメモリのどこかにある可能性があります。

  1. アプリケーションがメッセージを表示した時点でクラッシュ ダンプを取得します。
  2. SysInternals Stringsユーティリティを使用して、ダンプのすべての文字列をダンプします。
  3. C:\などの出力をコマンドにD:\パイプして直接フィルタリングするかfind、後で分析するためにテキスト ファイルにリダイレクトします。

これでも多くのファイルが残るため、原因を見つけることは以前のアプローチよりもはるかに簡単ではありません. ここでも、他のツールを使用してリストを絞り込みますhandle。

  1. アプリケーションがメッセージを表示した時点でクラッシュ ダンプを取得します。
  2. WinDbg でダンプを開きます
  3. スタック上で見つけたいくつかのアドレスの文字列をダンプします。NTFS のファイル名は Unicode であるため、du <address>ここでは問題なく動作するはずです。

これには間違いなく、適切なポインターを見つける場所など、内部的なものに関するより多くの知識が必要です。

初回例外の分析

アプリケーションが例外に依存している場合は、最初の例外を確認することで洞察を得ることができます。ただし、アプリケーションが適切な前提条件チェックを行うと、例外が少なくなるため、有用なものを取得する可能性が低くなります。

状況がうまく再現できれば、

  1. Image File Execution Optionsを使用して、WinDbg をそのプロセスのデバッガーとして設定します。
  2. でログファイルを開く.logopen /t /u c:\firstchanceexceptions.log
  3. を使用してすべての例外をダンプしsxe -c ".exr -1;k;g" *ます。そのgコマンドの はすぐに続行されるため、アプリケーションは (できれば) タイムアウトにならないようにします。
  4. で実行を続けるg
  5. アプリケーションが終了したら、ログファイルを閉じます.logclose
  6. 興味深い例外/興味深いコール スタックのログ ファイルを確認します。
  7. エラーを再現しますが、今回は興味深い例外で停止します
  8. ファイル名が見つかるかどうか、メソッドのパラメーターとメモリを調べます (ここでも を使用しますdu <address>) 。

メッセージ ボックスに属するアプリケーションを見つける

メッセージのタイトルが間違っているなどの理由で、エラー メッセージが表示されているアプリケーションがわからない場合は、次のようにします。

  1. SysInternals Process Explorerをダウンロードして実行します。

  2. ツールバーから十字線をウィンドウにドラッグします。

  3. Process Explorer は、ウィンドウを所有する実行可能ファイルを強調表示するようになりました

ファイル名が印刷されている場合のロックアプリケーションの検索

ダイアログに「%s」だけでなくファイル名が表示される場合:

  1. Process Explorer も使用する

  2. 検索/検索ハンドルまたは DLL を使用するか、Ctrl+キーを押しますF

  3. ファイル名またはファイル名の一部を入力します

于 2014-06-01T20:58:18.373 に答える