Delphiマルチスレッドプログラムで奇妙な0x0eedfade例外

Question

私はマルチスレッドサーバに奇妙な問題があります。これはWindowsサービスであり、多くのクライアントとのソケット接続を管理するFTPサーバーと同様に動作します。 Delphi 2006（Turbo Delphi）を使用して作成され、ほとんどのマシンでうまく機能します。残念なことに、いくつかのマシンでは、それ自体からトレースがなくてもクラッシュすることがあります（例外はログに保存する必要がありますが、そうではありません）。時には、システムは（それがサービスからのメッセージボックスではありませんが、私はそれがシステムメッセージボックスだと思う）メッセージボックスを示しているが、ほとんどの場合、私は、システムのEventLogでそのような情報を参照してください：アプリケーションのEventLogで

Application popup: ht_switch.exe - Application Error : The exception unknown software exception (0x0eedfade) occurred in the application at location 0x77e4bef7. 

私が見ることができます：

Faulting application ht_switch.exe, version 1.2.0.2, faulting module kernel32.dll, version 5.2.3790.5069, fault address 0x0000bef7. 

を

時々、これらのエントリはアプリケーションまたはシステムイベントログにありますが、何も起こりません - 私のサーバは通常通り動作しますが、単に消えてしまうことがあります。その後、Service Managerは私のサービスが予期せず停止したことをEventlLogに報告します。

このような問題に対して「共通の」シナリオはありません。 WinXP、Win2003、Win2008の一部に表示されます。すべてのテストマシンには、すべてのMSパッチが適用されています。

私は0x0eedfade kernelbase.dll faulting module in d7 windows serviceの回答を読んでいますが、Dialogユニットは使用していません。

修復するにはどうすればよいですか？そのような0x0eedfadeの例外をトレースする方法は？私は数日間EurekaLogとmadExceptの両方で自分のサーバーをテストし

EDIT

。

EurekaLog：

Serverは問題なく動作します。 EventLogに例外は報告されません。 %AppData%\EurekaLab s.a.s\EurekaLog\Bug Reports\に例外は報告されていません（私のプログラム用のディレクトリが必要ですが、作成されていません。作成する必要があるのか​​、それともEurekaLogのエラーなのか分かりません）。

EurekaLog7には、Windowsサービスに「アプリケーションタイプ」を設定する際に問題があります。それは既知の問題であり、著者がそれに取り組んでいます。私のサービスはWinXPで動作しますが、Win2003では動作できませんでした。それは単に始まらない。

madExcept：

Serverは、4時間のために働いたと墜落しました。私はスレッド内でこの例外をキャッチしました：

EAccessViolation: Access violation at address 7C90100B in module 'ntdll.dll'. Read of address 00000018!!! 

この例外に関するmadExceptレポートはありませんでした。この例外の後に、ソケットがCLOSE_WAIT状態（他の側が閉じている接続）で1つのスレッドが失われました。その後、サービスを再開し、数時間後に問題なく動作しました。

無効EurekaLogとmadExcept：

10〜30分後には、私はエラーでメッセージボックスを参照してください。しかし、0x0eedfadeエラーは謎めいており、問題の原因に関するヒントは表示されません。そのようなメッセージサービスを表示した後は問題なく（ほとんどの場合）動作するので、非常に奇妙です。

概要OD例外インターセプタ：

EurekaLogとmadExceptはおそらくデルファイで発生する例外では優れているが、私のサービスと誤差の変化挙動が魔法のように消えたと思われたり、彼らは私が見つけることができません配置するために、例外を報告しています。

EDIT：問題は、私はどこにも私はそれを辞任し、最後にコミットした変更を検査し始めた（非常に奇妙な場所でコールスタックしない）につながるいくつかのデバッグ後

を解決しました。 1つの変更は、文字列（AnsiString）の長さが64または128（ある種のビットマスク）である文字列操作でした。以前はSetLength(buffer, 64)で割り当てられた文字列の70番目の文字を設定しました。それが問題でした。私は範囲チェックを有効にすることで時間を節約できると思う。

Answer 1

このような0x0eedfade例外をトレースする方法はありますか。

これはDelphiの例外のコードです。明らかに、処理されていないDelphiの例外が発生し、そのプロセスがダウンしています。

あなたのプロセスにmadExcept、EurekaLog、JCLDebugなどを追加する必要があります。これらのツールは、プロセスが失敗したときに診断レポートを生成します。これらのレポートの最も有用な部分は、障害発生時のスタックトレースです。少なくとも、どこで障害が発生したかを調べることができなければなりません。これは通常、コードの問題を解決するのに十分です。