Mysterious IL offset of the WER report

Question

I am trying to parse the Windows Error Reporting report(Report.wer).

Here is a portion of the report:

Version=1
EventType=CLR20r3

... snip ...

Sig[0].Name=問題の署名 01
Sig[0].Value=myapp.exe
Sig[1].Name=問題の署名 02
Sig[1].Value=2.2.0.1
Sig[2].Name=問題の署名 03
Sig[2].Value=541bc264
Sig[3].Name=問題の署名 04
Sig[3].Value=System
Sig[4].Name=問題の署名 05
Sig[4].Value=2.0.0.0
Sig[5].Name=問題の署名 06
Sig[5].Value=4a275e12
Sig[6].Name=問題の署名 07
Sig[6].Value=2919
Sig[7].Name=問題の署名 08
Sig[7].Value=ef
Sig[8].Name=問題の署名 09
Sig[8].Value=System.IO.IOException

... snip ...

(where 問題の署名 means Problem Signature.)

Taught by SO Deciphering the .NET clr20r3 exception parameters P1..P10, I figured out that:

Faulting assembly is System of ver.2.0.0.0.
Faulting method token is 06002919.
Faulting IL offset is ef.

But the problem is the IL offset value ef.

The method 06002919 of System doesn't have IL_00ef.

Here is the definition of the method 06002919:

  .method /*06002919*/ assembly hidebysig 
          instance bool  Poll(int32 microSeconds,
                              valuetype System.Net.Sockets.SelectMode/*0200059D*/ mode) cil managed
  {
    // コード サイズ       81 (0x51)
    .maxstack  4
    .locals /*11000641*/ init (class System.Net.Sockets.Socket/*020005A0*/ V_0,
             object[] V_1)
    IL_0000:  ldarg.0
    IL_0001:  ldfld      bool System.Net.Sockets.NetworkStream/*02000547*/::m_CleanedUp /* 040027EA */
    IL_0006:  brfalse.s  IL_0019

    IL_0008:  ldarg.0
    IL_0009:  call       instance class [mscorlib/*23000001*/]System.Type/*01000065*/ [mscorlib/*23000001*/]System.Object/*01000001*/::GetType() /* 0A00006C */
    IL_000e:  callvirt   instance string [mscorlib/*23000001*/]System.Type/*01000065*/::get_FullName() /* 0A000136 */
    IL_0013:  newobj     instance void [mscorlib/*23000001*/]System.ObjectDisposedException/*01000179*/::.ctor(string) /* 0A0006A9 */
    IL_0018:  throw

    IL_0019:  ldarg.0
    IL_001a:  ldfld      class System.Net.Sockets.Socket/*020005A0*/ System.Net.Sockets.NetworkStream/*02000547*/::m_StreamSocket /* 040027E5 */
    IL_001f:  stloc.0
    IL_0020:  ldloc.0
    IL_0021:  brtrue.s   IL_0048

    IL_0023:  ldstr      "net_io_readfailure" /* 70011B97 */
    IL_0028:  ldc.i4.1
    IL_0029:  newarr     [mscorlib/*23000001*/]System.Object/*01000001*/
    IL_002e:  stloc.1
    IL_002f:  ldloc.1
    IL_0030:  ldc.i4.0
    IL_0031:  ldstr      "net_io_connectionclosed" /* 70011BBD */
    IL_0036:  call       string System.SR/*02000009*/::GetString(string) /* 06000029 */
    IL_003b:  stelem.ref
    IL_003c:  ldloc.1
    IL_003d:  call       string System.SR/*02000009*/::GetString(string,
                                                                 object[]) /* 06000028 */
    IL_0042:  newobj     instance void [mscorlib/*23000001*/]System.IO.IOException/*01000161*/::.ctor(string) /* 0A0006FD */
    IL_0047:  throw

    IL_0048:  ldloc.0
    IL_0049:  ldarg.1
    IL_004a:  ldarg.2
    IL_004b:  callvirt   instance bool System.Net.Sockets.Socket/*020005A0*/::Poll(int32,
                                                                                   valuetype System.Net.Sockets.SelectMode/*0200059D*/) /* 06002CDB */
    IL_0050:  ret
  } // end of method NetworkStream::Poll

Am I misreading something? How can I decipher the WER report correctly?

The source System.dll of the IL dump above is taken from GAC(C:\Windows\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089) on my development machine, not the target machine.

There are a lot of revisions of this DLL around, the one you used is very old. I'll take a blind guess that you used the reference assembly from c:\windows\microsoft.net\framework. You need a copy of System.dll as stored in the GAC in c:\windows\assembly, preferably from that machine. But foregone conclusion that if the metadata token is correct then the native select() function call failed. If only you knew why :) [Read this](https://msdn.microsoft.com/en-us/library/ty48b824%28v=vs.110%29.aspx). — Hans Passant, Dec 28 '15 at 12:32
@HansPassant Hmm, do you mean there are various revisions of System.dll that seem to have same version of 2.0.0.0? — Ripple, Dec 28 '15 at 14:02
I got System.dll from GAC on my developer PC(not the target machine). Anyway I will add how I get that later. — Ripple, Dec 28 '15 at 14:07

score 2 · Accepted Answer · answered Dec 28 '15 at 12:51

2

The problem is most likely caused by discrepancies between System.dll on machine where you try to decode WER log and machine where the exception has happened. Grab System.dll from the machine where the exception has happened and use that one.

For instance on my computer this token (06002919) leads to Timer constructor :)

.class /*0200054C*/ abstract auto ansi nested assembly beforefieldinit Timer
...
{
  ...
  .method /*06002919*/ assembly hidebysig specialname rtspecialname 
        instance void  .ctor(int32 durationMilliseconds) cil managed
  {
    ...
    IL_0018:  ret
  } // end of method Timer::.ctor
}

answered Dec 28 '15 at 12:51

Ondrej Svejdar

21,349
5
54
89

Thank you very much for the answer. Unfortunately, the target machine is in a factory guarded by strict security control, so I cannot grab that easily... But I will try to check some machines around me. – Ripple Dec 28 '15 at 14:47
I've verified that there are various file versions (2.0.50727.nnnn) of System.dll and all of them have the same assembly version 2.0.0.0. I suppose this is the answer. – Ripple Dec 29 '15 at 05:09
Now I've got the DLLs from the target machine and found that System.dll is 2.0.50727.4927, where the method `06002919` is `NetworkStream::BeginRead` and it has `IL_00ef`. Thanks a lot. – Ripple Jan 25 '16 at 09:06

Mysterious IL offset of the WER report

1 Answers1