.Net Frameworkの例外がイベントログに残らない


int.Parseをわざと失敗させ、例外を発生させてみたところ、
イベントログにそれらしい記録が残っていません。
try-catchでハンドルはしていません。

こういうのが残ることを期待しています。
https://blogs.msdn.microsoft.com/jpvsblog/2011/03/07/net-12471/

残さない設定などがあるのでしょうか?
それともint.Parseの失敗くらいではログに載らないのでしょうか?

環境:
Windows 7
Visual Studio 2012
.Net Framework 4.5

回答の条件
  • 1人5回まで
  • 登録:2018/09/21 17:43:34
  • 終了:2018/10/21 17:45:05

回答(2件)

id:SweetSmile1978 No.1

SweetSmile1978回答回数195ベストアンサー獲得回数292018/09/28 11:36:29

ポイント50pt

.NET Framework は例外を投げてくれますが
実際にそれをどう処理するかはアプリケーション側の責任です。
基本的には自分でイベントログに書き込む必要があります。

そのページに乗っているようなイベントログは
例外を投げることが難しい(例外をキャッチしても回復させることができない)ようなときに
ランタイム側で最終的な情報として出しているものなのではないかとおもいます。

id:kaoato No.2

kaoato回答回数155ベストアンサー獲得回数642018/10/16 22:43:27

ポイント50pt

>それともint.Parseの失敗くらいではログに載らないのでしょうか?

たぶん、そう。



.NET Framework アプリケーションの異常終了は、大きく分けて以下の 2 種類の例外によって発生します。


a) アプリケーションでハンドルされない一般的なマネージ例外
b) .NET Framework の内部処理で発生する例外


a) については、多くの方が経験されたことがありイメージしやすいかと思います。

例えば、未初期化のオブジェクトにアクセスしようとすると NullReferenceException がスローされますが、try-catch ステートメントで例外をハンドルしていない場合はアプリケーションが終了します。この問題は、Visual Studio や WinDbg などのデバッガを使用してアプリケーションをデバッグ実行するか、アプリケーション終了時のプロセスのダンプ ファイルを取得し、解析することで原因を調査することが可能です。デバッグ方法についての解説はここでは割愛します。

一方、b) については馴染みのない開発者の方も多いかもしれません。

これらは、通常、再現性が低く、問題発生時には「致命的な実行エンジン エラー」として ID 1000、および ID 1023 のイベント ログが記録されたり、アクセス違反の例外 (例外コード : 0xC0000005) として記録されたりします。これらの問題は、.NET Framework のコア ランタイム ライブラリ (mscorwks.dll または clr.dll) の内部処理でアクセス違反の例外が発生しているもので、イベント ログにもこれらのモジュールの名前が記録されます。(mscorwks.dll は .NET Framework 2.0/3.0/3.5 で使用される .NET Framework のコア ランタイム ライブラリです。clr.dll は .NET Framework 4 以降で使用されるものです。)

https://blogs.msdn.microsoft.com/jpvsblog/2014/09/16/net-framework/


・質問で発生させた例外の事例は、a)の場合である。
・質問に書かれているURL先のイベントログに書かれてるケースは b)のケースである。

質問に書かれている
https://blogs.msdn.microsoft.com/jpvsblog/2011/03/07/net-12471/
「ID 1000 もしくは ID 1023 」となってるので、間違いないと思う。

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません