3

私はレガシーDelphiアプリケーションのメンテナーです。このプログラムを実行しているマシンApplication Errorでは、このDelphiアプリを参照するキャプションと次のようなメッセージが表示されることがあります。

「...」の命令は「...」のメモリを参照していました。メモリを「読み取る」ことができませんでした。

[OK]をクリックして、プログラムを終了します。

タスクマネージャーによると、このメッセージボックスに属するプロセスはcsrss.exeです。このエラーの根本的な原因を見つけるための体系的な方法は何でしょうか？

問題は、このDelphiプログラムはかなり複雑であり、エラーメッセージが比較的まれにしか表示されないため、コードをステップスルーしてエラーの原因となる部分を見つけることができないことです。さらに、アプリはユーザーの邪魔をせずに自動的に実行されるため、メッセージが表示されたときにユーザーに何をするかを尋ねることはできません。アプリケーションログとシステムログは問題を示していません。メッセージボックスが表示されても、アプリは動作を停止しません。

誰かが以前にそのようなエラーメッセージに遭遇し、問題を解決できたことを願っています。よろしくお願いします。

4

2 に答える 2

7

csrssWindows コンソールをサポートします。あなたのアプリケーションはコンソール サブシステムをターゲットにしていると思います。

デバッガーでアプリケーションを失敗させることができない場合は、診断を追加する必要があります。これを行うには、madExcept や EurekaLog などのツールを使用することをお勧めします。個人的には madExcept を使用していますが、あまりお勧めできません。私が聞いたところによると、EurekaLog も優れた製品です。

これらのツールの 1 つをアプリケーションに統合すると、次にエラーが発生したときに詳細な診断レポートが生成されます。最も重要なのは、プロセス内の各スレッドのスタック トレースを取得することです。フォールト スレッドのスタック トレースから、プログラムのバグの根本原因を突き止めることができます。

私が持っている疑問は、障害が発生している場合、csrssプロセスに診断を含めても成果が得られない可能性があるということです. アプリケーションですでにエラーが発生している可能性が高く、その結果、 のエラー メッセージが表示されcsrssます。その場合、アプリの診断が役立ちます。そうでない場合は、プロセスで障害を発生させる方法を見つける必要があるかもしれません。

于 2013-02-12T09:32:55.290 に答える
6

Davidの推奨に加えて、 sysinternalsのprocdumpを使用してプロセスを監視し、未処理の例外が発生したときにダンプファイルを書き込むことをお勧めします。

Windbgなどを使用してダンプファイルをオフラインで分析できます。それは最初はやり過ぎに思えるかもしれませんが、Windbgに慣れるまでには、多くのことを得ることができると強く信じています。

序章

ProcDumpはコマンドラインユーティリティであり、その主な目的は、アプリケーションのCPUスパイクを監視し、スパイク中にクラッシュダンプを生成することです。これを使用して、管理者または開発者がスパイクの原因を特定できます。ProcDumpには、ハングしたウィンドウの監視（Windowsおよびタスクマネージャーが使用するのと同じウィンドウハングの定義を使用）、未処理の例外監視が含まれ、システムパフォーマンスカウンターの値に基づいてダンプを生成できます。

例

プロセスを起動し、例外がないか監視します。

   C:\>procdump -e 1 -f "" -x c:\dumps consume.exe
于 2013-02-12T11:48:02.637 に答える