0

私は現在、アンマネージC++アプリケーションのクラッシュ/例外を解決しようと取り組んでいます。

アプリケーションは、ある程度の予測可能性を持ってクラッシュします。プログラムは基本的に、アクセスDBを介して一連のクエリを実行することと組み合わせて、大量のファイルを処理します。

それは間違いなくファイルアクセス中に発生しています。エラーメッセージは次のとおりです。

         "failed reading. Network name is no longer available."

同じ低レベルのファイルアクセスコードで常にクラッシュしているようです。下位レベルのライブラリSeek()を実行し、次にRead()を実行します。読み取り中に例外が発生します。

さらに複雑なことに、ディスクバランシングユーティリティを実行しているときにのみエラーが発生する可能性があります。ユーティリティは基本的にファイルアクセス履歴を調べ、より頻繁に/最近使用されたファイルをより高速なストレージ検索に移動し、あまり使用されていないファイルはより低速な検索領域に移動します。この特定のストレージデバイスのアーキテクチャを完全には理解していませんが、基本的には「高速」検索用の領域と「アーカイブ/低速」用の領域があります。

ユーティリティアプリを数回起動および停止すると、問題はより簡単に/予測可能に再現できます。ディスクの製造元によると、クライアントのメインアプリケーションの動作に影響を与えることなく、ユーティリティをバックグラウンドで実行できるはずです。

ここで進める方法について何か提案はありますか?この辺りには、ストレージデバイスの遅延に何らかの形で関係しているという理論が浮かんでいます。それを証明/反証する方法はありますか?基本的にドライブ上のファイルの混乱全体にアクセス/読み取りを行う小さなサンプルアプリを作成しました。SmartPoolsを使用しても、(これまでのところ)問題を再現することはできませんでした。私の考えは、レイテンシー理論をプッシュしようとすることです。ユーティリティアプリケーションの実行中に、複数のアプリが基本的にディスクから大量のファイルを読み取るようにすることです。

メモリ使用量とCPU使用率は、タスクマネージャでラインから外れているようには見えません。

考え?これは少し毛玉になりつつあります。

ありがとう、JohnB

4

1 に答える 1

0

デバッグ バイナリを取得します。Application Verifier をセットアップし、アプリケーションをそのリストに追加します。うまくいけば、クラッシュダムを待ちます。それをWinDBGに通します。コマンドを試してみてください: !avrf 何が得られるか見てみましょう....

于 2012-09-26T17:52:24.167 に答える