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

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

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

＞それとも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 」となってるので、間違いないと思う。