Answer 1

The code  actually throws an AV exception, it is CLR who wrap the exception to NullReference exception.

See:

How does the CLR decide if a given AV should be converted to a NullReferenceException or not?

Why can't NullReferenceException tell you the type of the instance that was null?

Answer 2

It still does not answer my question. Like i mentioned there is a NullReference exception on the stack and it is created.

I did also have a bp on the NullReference constructor, how come when i do sxe -c "!clrstack;!pe" clr  it does not break, when the exception is created.

And if i debug it in VS.NET i can catch the exception.

Answer 3

In managed world, there are many exception types, for example: ArgumentNullException and NullReferenceException, from perspective of SEH, all of those exceptions share same error code: 0xe0434352, in WinDbg, we use item ‘CLR exception’ for this error code.

“sxe” command enables first chance exception handling, in another words, WinDbg will break the debuggee immediately after the target process generates an exception, at this time, the debuggee’s exception handling code  doesn’t get chance to execute.

When we use command “sxe clr“ to enable clr  exception, WinDbg will break once an error with code 0xe0434352 occurs. But, your code snippet actually generate an  Access Violation exception which has error code 0xC0000005, that’s why you only see a first chance AV exception,

you may throw a NullReferenceException from your code and use WinDbg to test again:

            try

            {

                thrownew NullReferenceException();

            }

            catch

            {

                Console.WriteLine("error");

                Console.ReadLine();

            }

In WinDbg, you will see something like this:

(1ba4.1aec): CLR exception - code e0434352 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=01831228 ebx=00000000 ecx=00000000 edx=00000000 esi=003805f8 edi=001ff120

eip=005100b2 esp=001ff0cc ebp=001ff0f4 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

Here, we got a CLR exception, if you set a breakpoint at System.NullReferenceException..ctor() method:

0:000> !name2ee mscorlib.dll System.NullReferenceException

Module:      553f1000

Assembly:    mscorlib.dll

Token:       02000108

MethodTable: 5570470c

EEClass:     55441cb4

Name:        System.NullReferenceException

0:000> !dumpmt -md 5570470c

EEClass:      55441cb4

Module:       553f1000

Name:         System.NullReferenceException

mdToken:      02000108

File:         C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll

BaseSize:        0x54

ComponentSize:   0x0

Slots in VTable: 21

Number of IFaces in IFaceMap: 2

--------------------------------------

MethodDesc Table

   Entry MethodDesc      JIT Name

55616af8   5546c584   PreJIT System.Exception.ToString()

…

555ed1a8   55460b0c   PreJIT System.NullReferenceException..ctor()

55c33344   55460b1c   PreJIT System.NullReferenceException..ctor(System.String)

55c33374   55460b28   PreJIT System.NullReferenceException..ctor(System.String, System.Exception)

55c333b0   55460b34   PreJIT System.NullReferenceException..ctor(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)

0:000> !bpmd -md 55460b0c  

MethodDesc = 55460b0c

Setting breakpoint: bp 55C33304 [System.NullReferenceException..ctor()]

And input commang ‘g’ to let the AV exception to be thrown, the breakpoint at System.NullReferenceException..ctor() will be hit:

0:000> g

(1ba4.1aec): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=01831228 ebx=00000000 ecx=00000000 edx=00000000 esi=003805f8 edi=001ff120

…

0:000> g

Breakpoint 7 hit

eax=55460b0c ebx=00000000 ecx=0183cafc edx=001fe790 esi=003805f8 edi=001fe6e0

eip=55c33304 esp=001fe6b8 ebp=001fe6c4 iopl=0         nv up ei pl nz ac pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216

mscorlib_ni!System.NullReferenceException..ctor():

55c33304 55              push    ebp

0:000> k

ChildEBP RetAddr 

001fe6c4 56dd21db mscorlib_ni!System.NullReferenceException..ctor()

001fe6c4 56df4a2a clr!CallDescrWorker+0x33

001fe740 56df4bcc clr!CallDescrWorkerWithHandler+0x8e

001fe87c 56df4c01 clr!MethodDesc::CallDescr+0x194

001fe898 56ebc74f clr!MethodDesc::CallTargetWorker+0x21

001fe9d8 56ec9269 clr!CallDefaultConstructor+0x154

001fea38 57047842 clr!EEException::CreateThrowable+0x94

001feaf4 56fb2e38 clr!CreateCOMPlusExceptionObject+0x179

001fec5c 56e5cbbf clr!CPFH_RealFirstPassHandler+0x383

001fecb4 56e5ccfe clr!CPFH_FirstPassHandler+0xe6

001fece0 77cb65f9 clr!COMPlusFrameHandler+0x132

001fed04 77cb65cb ntdll!ExecuteHandler2+0x26

001fedb4 77cb6457 ntdll!ExecuteHandler+0x24

001fedb4 005100b2 ntdll!KiUserExceptionDispatcher+0xf

001ff0f4 56dd21db ConsoleApplication2!ConsoleApplication2.Program.Main(System.String[])+0x42 [D:\Workspace\Projects\2010\ConsoleApplication2\ConsoleApplication2\Program.cs @ 19]

….

001ffcfc 00000000 ntdll!_RtlUserThreadStart+0x1b [d:\w7rtm\minkernel\ntos\rtl\rtlexec.c @ 3111]

0:000> !do 0183cafc

Name:        System.NullReferenceException

MethodTable: 5570470c

EEClass:     55441cb4

Size:        84(0x54) bytes

File:        C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll

Fields:

      MT    Field   Offset                 Type VT     Attr    Value Name

5570f9ac  400004a        4        System.String  0 instance 00000000 _className

557101f4  400004b        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod

5570f9ac  400004c        c        System.String  0 instance 00000000 _exceptionMethodString

5570f9ac  400004d       10        System.String  0 instance 00000000 _message

55704004  400004e       14 ...tions.IDictionary  0 instance 00000000 _data

5570fc0c  400004f       18     System.Exception  0 instance 00000000 _innerException

5570f9ac  4000050       1c        System.String  0 instance 00000000 _helpURL

5570f5e8  4000051       20        System.Object  0 instance 00000000 _stackTrace

5570f5e8  4000052       24        System.Object  0 instance 00000000 _watsonBuckets

5570f9ac  4000053       28        System.String  0 instance 00000000 _stackTraceString

5570f9ac  4000054       2c        System.String  0 instance 00000000 _remoteStackTraceString

55712978  4000055       3c         System.Int32  1 instance        0 _remoteStackIndex

5570f5e8  4000056       30        System.Object  0 instance 00000000 _dynamicMethods

55712978  4000057       40         System.Int32  1 instance        0 _HResult

5570f9ac  4000058       34        System.String  0 instance 00000000 _source

5570aa2c  4000059       44        System.IntPtr  1 instance        0 _xptrs

55712978  400005a       48         System.Int32  1 instance        0 _xcode

556ca29c  400005b       4c       System.UIntPtr  1 instance        0 _ipForWatsonBuckets

556c9888  400005c       38 ...ializationManager  0 instance 00000000 _safeSerializationManager

0:000> .exr 001fedcc

ExceptionAddress: 005100b2 (ConsoleApplication2!ConsoleApplication2.Program.Main(System.String[])+0x00000042)

   ExceptionCode: c0000005 (Access violation)

  ExceptionFlags: 00000000

NumberParameters: 2

   Parameter[0]: 00000000

   Parameter[1]: 00000000

Attempt to read from address 00000000

WinDbg is an “unmanaged debugger”, for WinDbg, all CLR exceptions are same because all of them has same error code, but SOS extension can helps to show more information about a specified CLR exception (e.g. use !pe command).

VS Debugger is a “managed debugger” by default, it has different mode against WinDbg, we no need to load SOS in VS Debugger, instead, with the help of managed debugging API, VS Debugger knows all information about a CLR exception, so you received a NullReferenceException instead of an AV exception in VS.

VS Debugger can also act as an “unmanaged debugger”:

1. Launch target application.

2. In VS, select ToolsàAttach to Process,

3. on the pop up dialog, you can see a button has text “Select…”, click this button, on the pop up dialog, select “Debug those code types:” radiobutton, and only tick checkbox of “Native”, click OK, then, select a process and click “Attach” button.

4. To let VS Debugger break when first chance AV exception occurs, select Debug à Exceptions, on the pop up, unwind ‘Win32 Exception’ node, tick the checkbox of ‘Access violation’, click OK.

5. Back to your application, let it execute Testing() method, then, VS Debugger will break with an AV exception.

Answer 4

Eric is right. 

To Summarize, not all clr  exceptions are implemented on top of the SEH exception code 0xe0434352 (which is what 'sxe clr' stops on).  There are some 'hardware exceptions' which Windows raises as SEH exceptions with specific codes, and so the CLR doesn't need to create it's own SEH exception for those.  True the CLR will still wrap them in an appropriate Exception object, but not necessarily as soon as they are thrown.  Another example is divide-by-zero.

So basically it's an implementation detail (driven by concerns for performance and interoperability with native code) of how the CLR implements .NET exceptions on top of Windows SEH.  A managed debugger (which operates at the CLR level of abstraction, rather than at the CPU/OS level like WinDbg) will abstract such details from you.  Using WinDbg, some implementation detials like this bleed through.

Rick

Answer 5

Thanks Rick.  Especially If I am troubleshooting something in production where there is only windbg, I would like to know list of SEH exception that would not be trapped by sxe clr. Has this been documented? Where can i get this information?