2

ソフトウェアの問題を検出するのに役立つ例外ハンドラルーチンを作成しました。私が使う

SetUnhandledExceptionFilter();

キャッチされない例外をキャッチするために、そしてそれは非常にうまく機能します。

しかし、私のハンドラーは、クラッシュ時に何をしていたかを詳細に説明するようにユーザーに求めるダイアログをポップアップ表示します。ここで問題が発生します。ダイアログはクラッシュと同じスレッドコンテキストにあるため、ダイアログは引き続きアプリケーションのメッセージを送り出します。クラッシュの1つがWM_TIMERにあり、毎分オフになるため、これにより問題が発生します。ダイアログが1分以上画面に表示されている場合に想像できるように、WM_TIMERがディスパッチされ、アプリが再クラッシュします。この状況で例外ハンドラーに再度入るのは悪いニュースです。

Windowsにクラッシュを処理させると、Windowsは機能しているように見えるダイアログを表示しますが、アプリケーションの残りの部分に伝播するメッセージを停止するため、WM_TIMERは再発行されません。

誰かが私が同じ効果を達成する方法を知っていますか？

ありがとうリッチ

4

2 に答える 2

2

CreateProcess()おそらく、未処理の例外を検出したときにを使用して、別のデータ収集プロセスを起動できます。この個別のプロセスにより、ユーザーは自分が行っていることに関する情報を入力するよう求められますが、メインアプリケーションは引き続きクラッシュして終了する可能性があります。

または、別のプロセスを開始したくない場合は、別のメッセージキューを使用して別のスレッドを作成し、ダイアログが画面に表示されている間はメインスレッドが何も実行できないようにすることができます。WM_TIMERメインスレッドがブロックされている間は、メッセージを処理する機会がありません。

于 2010-02-19T10:19:48.983 に答える
0

2番目のスレッドでダイアログを表示します。私は多かれ少なかれ同じ問題を抱えていました（しかし、ダイアログではなくメッセージボックスを表示する必要がありました）。

  • Win32CreateEvent関数を使用して2つのイベントを作成するクラスを作成します。1つのイベント（トリガー）はダイアログをトリガーするために使用され、1つのイベント（準備完了）はダイアログが処理されたことを通知するために使用されます。
  • クラスにメソッド'execute'を追加し、このメソッドを2番目のスレッドで開始します
  • 'execute'メソッドをトリガーイベントが設定されるまで待機させ、設定されている場合はダイアログを表示します
  • ダイアログが処理されたら、「準備完了」イベントを設定します。
  • アプリケーションがメインスレッドでクラッシュした場合は、（クラスのセッターを介して）ダイアログの情報を準備し、「trigger」イベントを設定してから、「ready」イベントを待ちます。トリガーイベントを設定すると、2番目のスレッドがアクティブになり、メインスレッドは、2番目のスレッドが「ready」イベントを設定するまでブロックされます。
于 2010-02-19T10:21:28.860 に答える