次の方法で共有


プログラムがエラー無しで強制終了する原因について

質問

2010年8月18日水曜日 10:17

はじめまして、C#で開発のアルバイトをしているものです。

現在、作成中のアプリケーションが特定の操作時にエラー・警告等がまったく出ないまま強制終了してしまう

という問題に悩まされています。通常、アプリケーションが強制終了する際、アプリケーション側、もしくはOS側から

警告メッセージが表示されると思うのですが、今回のケースではそのような表示がまったくないままアプリが突然終了してしまいます。

同じ操作をしても毎回強制終了するわけではなく、ごくたまに出る程度なので、再現性などもきちんと考察出来ていません。

作っているアプリは、顧客に対して諸々の計測を行い、結果をレポートとしてPDFに出力するというもので、

計測の一部を他社製のソフトにより行い、計測結果をAPIから取得し、統合しています。

実際に上記の問題が起こる処理の流れは以下の通りです。

・アプリケーション側から別な計測アプリ(他社製)を起動する。呼び出し側は最小化し、BackgroundWorkerで終了監視を行う。

・起動したアプリ上で操作を行う。

・操作完了後、サーバーにデータを送信してこのアプリを終了する。

・呼び出し側に処理が戻り、サーバーに送信されたデータをAPIから取得し画面に反映する。

・この時に行える操作は以下の3つ

・自社サーバーにデータを送信し、保存する。

・自社アプリを用いて追加計測を行う。

・レポートをPDFとして出力する。(iTextSharpというライブラリを使用)

・問題が起こるのは他社製ソフトでの計測直後にPDFを出力した場合のみ。その他の場合では同様の問題は報告されていない。

個人的には、通常のバグではなく、OS側に起因する問題なのではないかという気がしているのですが、

このような現象が起こる場合、原因としてはどのようなものが考えられますでしょうか?

どなたか詳しい方がいらっしゃいましたら、教えていただけると幸いです。

何卒、よろしくお願いいたします。

すべての返信 (13)

2010年8月18日水曜日 12:37 ✅回答済み

別にEnvironment.Exit()やExitProcess()、TerminateProcess()を呼び出せば、強制終了できます。そのほかにも手段はあるでしょう。

OS側に起因する問題と判断した理由はなんでしょうか? ご自身で理解できない動作だから、だとするとあまりにも軽率です。OS側に起因するならば、イベントログに何らかの出力があると思いますので確認するといいでしょう。それがないのであれば、アプリケーションか使用されているライブラリに起因する可能性が高いです。

C#(.NET)として正常終了しているのであれば、AppDomain.ProcessExitイベント が発生するでしょうから、このイベントを見て判断することもできるでしょう。


2010年8月18日水曜日 13:49 ✅回答済み

個人的には、通常のバグではなく、OS側に起因する問題なのではないかという気がしているのですが、
このような現象が起こる場合、原因としてはどのようなものが考えられますでしょうか?

その推測は速すぎます。
ネイティブコードでバグがあって不正終了したり、別スレッドで問題が起きたりなどすると、無言で落ちることはよくあります。

AppDomain の UnhandledException イベントにイベントハンドラを設定して、ExceptionObject の Message を記録するとかすれば、何か見えてくるかもしれませんね。
http://msdn.microsoft.com/ja-jp/library/system.appdomain.unhandledexception(VS.80).aspx

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。


2010年8月19日木曜日 16:02 ✅回答済み

ただ一つ気になるのが、AppDomainのUnhandledExceptionはデフォルトでイベントハンドラが設定されているので何も設定しなくてもエラーメッセージが出力されるはずです。

例外のスタックトレースが表示される標準のダイアログは、Application.ThreadException の方です。
こちらはメッセージループの中で発生したハンドルされていないダイアログについては表示されますが、ワーカースレッドなどのバックグラウンドスレッドについては表示されないことがあります。

ただ、佐祐理さんも指摘されていますように、先にイベントログに何か有力な情報がないか確認してみてください。
AppDomain.UnhandledException は有力な情報が得られなかった場合に打つ、次の手ぐらいで捉えてください。

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。


2010年8月19日木曜日 13:59

回答ありがとうございます!

なるほど。ご指摘の通りですね。OS側の問題としたのは早計でした。

エラーメッセージ等が出ないので、Exitが呼ばれたか.NETフレームワークやOSに回収されないエラーが起きたのだろうと推測したのですが、Exitが呼ばれた可能性を考えてみた時に、自分のソースコードにはそんな仕様はありませんし、ライブラリがエラーを出さずに内部でExitを呼ぶことも考えにくいので、後者だろうと。ただ、そこから先で起きうる原因が分からなくて・・・

アドバイスをいただいたように、取りあえずイベントを取得してログを取るようにしてみます。


2010年8月19日木曜日 14:11

その前にイベントログを見ましょうよ。


2010年8月19日木曜日 14:19

回答ありがとうございます。

うーん。先の方にもご指摘をいただきましたが、OSの問題と推測したのは早すぎましたね。。すみません。

なるほど、エラーが出ずに強制終了することは、それほど珍しいものではないのですね。エラーメッセージが出ないのは、.NETフレームワークやOSのエラー検出には引っかからないからという理解でよろしいでしょうか?

取りあえずアドバイスいただいた通り詳細にログを取って、問題個所を掘り下げてみたいと思います。

ただ一つ気になるのが、AppDomainのUnhandledExceptionはデフォルトでイベントハンドラが設定されているので何も設定しなくてもエラーメッセージが出力されるはずです。なので、この方法でログを取れるエラーというのは直接の原因となりえないのではという気もするのですが、上のようなエラーも実質的にはいくつかのUnhandledExceptionの連鎖であることが多いのでしょうか?

すみません、経験が浅くてこのような問題に対処する方法が良く分かっていないので、ご教示いただけると幸いです。

よろしくお願いいたします。


2010年8月20日金曜日 3:39

はい、やってみます。

顧客の店舗でないと検;できないので、十分なログが取れるまでに時間がかかるかもしれませんが、その上で煮詰まってしまったら、またご相談させてください。

丁寧に返答していただきありがとうございます。


2010年8月20日金曜日 3:44

例外のスタックトレースが表示される標準のダイアログは、Application.ThreadException の方です。
こちらはメッセージループの中で発生したハンドルされていないダイアログについては表示されますが、ワーカースレッドなどのバックグラウンドスレッドについては表示されないことがあります。

そうなのですね。勉強になります。

ただ、佐祐理さんも指摘されていますように、先にイベントログに何か有力な情報がないか確認してみてください。
AppDomain.UnhandledException は有力な情報が得られなかった場合に打つ、次の手ぐらいで捉えてください。

なるほど、分かりました。やってみます。

上にも書きましたが、少し検;に時間がかかってしまいそうです。もし煮詰まってしまったら、またご相談させてください。

本当にありがとうございました。

 

追記:すみません。。もう一点だけ。

もしワーカスレッドの問題でプログラムが無言落ちする場合は、どのようなことが原因として考えられるのでしょうか? 何分ログを取るのに時間がかかってしまうので、今のうちに潰せる問題は潰しておきたくて。どのようなところに配慮すれば、このような問題を避けることができるのでしょうか? この紙面で書ききれないことでしたら、もしこのような問題を詳しく扱った書籍、ページ等がありましたら、紹介していただけると嬉しいです。

何度もすみません。。よろしくお願いいたします。


2010年8月20日金曜日 11:59

だからログを取る前に既にあるイベントログを見ましょうよ。(3回目)


2010年8月20日金曜日 14:15

もしワーカスレッドの問題でプログラムが無言落ちする場合は、どのようなことが原因として考えられるのでしょうか? 何分ログを取るのに時間がかかってしまうので、今のうちに潰せる問題は潰しておきたくて。どのようなところに配慮すれば、このような問題を避けることができるのでしょうか?

いろいろな可能性があるので、情報もなしにつぶすことは非常に難しいです。
怪しいと思うところも、心当たりもないのであればまず無理です。

故に情報を入手することから始めてください。
(イベントログの有無の確認ぐらいは顧客か営業に協力してもらってください)

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。


2010年8月20日金曜日 16:40

だからログを取る前に既にあるイベントログを見ましょうよ。(3回目)

ん??あ、イベントログって矢のようなスピードで流れさって行くものではないのですね!誤解していたみたいです。

3回も言わせてしまってごめんなさい! 早速顧客のところに赴いて確認してみます。

 


2010年8月20日金曜日 16:51

いろいろな可能性があるので、情報もなしにつぶすことは非常に難しいです。
怪しいと思うところも、心当たりもないのであればまず無理です。

故に情報を入手することから始めてください。
(イベントログの有無の確認ぐらいは顧客か営業に協力してもらってください)

なるほど!

わかりました。アドバイスしていただいた通り、情報を集めるところから始めてみます。

ありがとうございました。


2010年9月6日月曜日 6:59

こんにちは、akirakiron さん。

MSDN フォーラムのご利用ありがとうございます。オペレーターの山本です。

その後いかがでしょうか。

問題の切り分けなどに有効な情報など、佐祐理 さんや Azulean さんからの情報が参考になっていると思われましたので、勝手ながら私のほうで一旦回答としてマークさせていただきました。
佐祐理 さんや Azulean さん、情報ありがとうございます。

いただいた情報の中で、問題の解決に役立ったものだけでなく、参考になる情報など有効な情報には、回答としてマークすることをお願いしています。
今後、同じ問題でこのスレッドを参照される方にも、有効な情報がわかりやすくなるかと思いますので、ご協力よろしくお願いいたします。

よろしければ、お時間のある時にでも、その後の状況をお知らせくださいね。
まだ解決されていない場合には、確認されているエラーの情報などとともに、ご質問を続けてくださいね。

今後とも、MSDN フォーラムをよろしくお願いいたします。それでは。
                                                                 
マイクロソフト株式会社 フォーラム オペレーター 山本 春海