2

フィールドにある特定のソフトウェアで、完全にランダムなエラーがポップアップ表示されます。このアプリケーションは、VB6 で作成されたゲームであり、Windows 7 64 ビットで実行されます。ときどきアプリがクラッシュし、一般的な「program.exe が応答を停止しました」というメッセージ ボックスが表示されます。このゲームは、このメッセージが表示されるまで何日も、または数時間以内に問題なく実行できます。例外はスローされていません。

このアプリは Windows 2000 互換モード (これが元の OS でした) で、ビジュアル テーマを無効にして、管理者として実行します。アプリ自体は、外部コンポーネントと API 呼び出しを使用するという点で意図的に単純化されています。

参考文献:

Visual Basic for Applications
Visual Basic ランタイム オブジェクトとプロシージャ
Visual Basic オブジェクトとプロシージャ
OLE オートメーション
Microsoft DAO 3.51 Object Library
Microsoft Data Formatting Object Library

コンポーネント:

Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT

ご覧のとおり、これらはほとんどの場合、非常に単純な Microsoft 標準ツールです。データベース コンポーネントは、簿記に使用される Access データベースと対話するために存在し、Resizer XTが挿入されて、このゲームを元の解像度 800x600 から 1920x1080 に簡単に移動できます。

キオスクではネットワークが有効になっていません。ネットワーク ドライバがないため、リモート データベースへの接続がありません。すべてが単一のボックスにカプセル化されています。

これが発生すると、Windows アプリケーション イベント ログにイベント ID 1000 が表示され、一見ランダムなモジュール (これまでのところ、ntdll.dll または lpk.dll) で障害が発生しています。API 呼び出しに関しては、ntdll.dll からのものは見当たりません。さまざまなファイル システムおよびサウンド機能に、kernel32、user32、および winmm を使用しています。完全にランダムであるため再現できないため、どこからトラブルシューティングを開始すればよいかさえわかりません。何か案は？

編集：もう少し情報。他の開発者の提案で、いくつかの異なるバージョンの Dependency Walker を試しましたが、最新バージョンでは、IESHIMS.dll と GRPSVC.dll が見つからないことがわかりました (これら 2 つは Depends.exe のよく知られたバグのようです)。 、COMCTRL32.dll と IEFRAME.dll にシンボルがありません。そこに手がかりはありますか？

4

2 に答える 2

6

アプリケーション イベント ログからのメッセージはそれほど役に立ちません。必要なのは、プロセスからの事後分析プロセス ダンプです。そのため、コードのどこで問題が発生したかを確認できます。

これらの問題のいずれかを目にするたびに、一般的には、よりエキゾチックなものではなく、不適切な API パラメーターに帰着します。これは、不適切なデータが入ってくることが原因である可能性がありますが、通常、問題を引き起こすのは古き良き時代のバグです。

すでにお気づきかもしれませんが、これはデバッグが容易ではありません。理想的には、リモート マシンからのダンプ ファイルのキャプチャに依存するのではなく、再現可能な失敗のケースをデバッグする必要がありますが、それが再現可能になるまでは、リモート ダンプが唯一の方法です。

以前はワトソン博士がこれを行っていましたが、出荷されなくなったため、代替手段は次のとおりです。

取得する必要があるのはミニダンプです。これらには、標準モジュール (Kernel32.dll など) を除くプロセス空間の重要な部分が含まれており、ダンプをバージョン番号に置き換えます。

プロセスがクラッシュしたときにダンプを自動的にキャプチャするための手順があります- デバッグ ツールに同梱されている cdb.exe を使用しますが、重要な項目はレジストリ キーです。\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

コードを変更してより適切なエラー処理を追加できます。原因をいくつかの手順に絞り込み、「シンボリック デバッグ情報を使用してプログラム クラッシュを特定する」で説明されている手法を使用できる場合は特に便利です。マップファイルを直接処理します。

ミニダンプとシンボル ファイルを取得したら、これらのダンプを掘り下げるためのツールとして WinDbg を選択しますが、原因を突き止めるには少々時間がかかります。

私が考慮したい唯一の他のことは、これはアプリケーションの構造によって異なりますが、再生のためにすべての入力イベントをキャプチャしようとすることです。

もう 1 つのオプションは、リプレイ デバッグを備えた VMWare 7.1 のコピーを見つけ、それを再現可能な一連の手順をキャプチャする最初の手順として使用することです。

于 2012-08-07T09:26:41.247 に答える