Is it normal to receive access violation exception (0xc0000005) after NullReference exception

Question

The big problem I am trying to solve is identify why in one of our managed application we are receiving from time to time a access violation exception (0xc0000005). Recently, on a completely different application we started to receive a NullReference exception (which is a know bug now), but it's followed by a (0xc0000005) error. I wonder if this is normal behaviour or it is related to our 'big problem'.

Access violation exception (2nd)

Faulting application name: Marketform.Ultimates.Client.exe, version: 0.27.0.0, time stamp: 0x52728ad4
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x08cac78a
Faulting process id: 0x10f4
Faulting application start time: 0x01ced7016881cca1
Faulting application path: C:\Users\vxk\AppData\Local\Apps\2.0\WZ2LJT6T.PKK\WEJ4X8PL.17E\mark..tion_5585060aa30c4020_0000.001e_06d3070c7f40068c\Marketform.Ultimates.Client.exe
Faulting module path: unknown
Report Id: b7d08351-42f4-11e3-802a-005056b87be9

NullReference exception (1st)

Application: Marketform.Ultimates.Client.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
Stack:
   at Marketform.Ultimates.Module.ViewModels.UltimatePremiumViewModel.CanSave()
   at Microsoft.Practices.Prism.Commands.DelegateCommand+<>c__DisplayClass6.<.ctor>b__3(System.Object)
   at Microsoft.Practices.Prism.Commands.DelegateCommandBase.CanExecute(System.Object)
   at Microsoft.Practices.Prism.Commands.DelegateCommandBase.System.Windows.Input.ICommand.CanExecute(System.Object)
   at Marketform.Ultimates.Module.DelegateCommandWrapper.CanExecute(System.Object)
   at MS.Internal.Commands.CommandHelpers.CanExecuteCommandSource(System.Windows.Input.ICommandSource)
   at System.Windows.Controls.Primitives.ButtonBase.UpdateCanExecute()
   at System.Windows.Controls.Primitives.ButtonBase.HookCommand(System.Windows.Input.ICommand)
   at System.Windows.Controls.Primitives.ButtonBase.OnCommandChanged(System.Windows.DependencyObject, System.Windows.DependencyPropertyChangedEventArgs)
   at System.Windows.DependencyObject.OnPropertyChanged(System.Windows.DependencyPropertyChangedEventArgs)
   at System.Windows.FrameworkElement.OnPropertyChanged(System.Windows.DependencyPropertyChangedEventArgs)
   at System.Windows.DependencyObject.NotifyPropertyChange(System.Windows.DependencyPropertyChangedEventArgs)
   at System.Windows.DependencyObject.UpdateEffectiveValue(System.Windows.EntryIndex, System.Windows.DependencyProperty, System.Windows.PropertyMetadata, System.Windows.EffectiveValueEntry, System.Windows.EffectiveValueEntry ByRef, Boolean, Boolean, System.Windows.OperationType)
   at System.Windows.DependencyObject.InvalidateProperty(System.Windows.DependencyProperty)
   at System.Windows.Data.BindingExpressionBase.Invalidate(Boolean)
   at System.Windows.Data.BindingExpression.TransferValue(System.Object, Boolean)
   at System.Windows.Data.BindingExpression.Activate(System.Object)
   at System.Windows.Data.BindingExpression.AttachToContext(AttachAttempt)
   at System.Windows.Data.BindingExpression.MS.Internal.Data.IDataBindEngineClient.AttachToContext(Boolean)
   at MS.Internal.Data.DataBindEngine+Task.Run(Boolean)
   at MS.Internal.Data.DataBindEngine.Run(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   at System.Threading.ExecutionContext.runTryCode(System.Object)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.InvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
   at System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame)
   at System.Windows.Application.RunDispatcher(System.Object)
   at System.Windows.Application.RunInternal(System.Windows.Window)
   at System.Windows.Application.Run(System.Windows.Window)
   at Marketform.Ultimates.Client.App.Main()

Answer 1

Yes, that's normal. There is no such thing as a "null reference exception" in Windows. These kind of pointer faults are reported by the processor with a general protection fault trap, that generates an access violation exception in the operating system. Exception code 0xc0000005.

Windows setS up the virtual memory for a process by always leaving the bottom 64KB, starting at address 0 unmapped. Specifically to detect pointer bugs, they are very common in programming. A NULL pointer will thus always trip the processor fault. As well as addresses somewhat larger than 0, generated when a program tries to access a field of an object through a null pointer.

The CLR intercepts the native access violation exception and looks at the address that caused the exception. If it is located within that 64KB address range then it raises System.NullReferenceException. If it is not then it raises System.AccessViolationException.

The top snippet were the diagnostics generated by Windows, the bottom by the CLR. The top one just shows the native exception code, Windows doesn't know anything about managed exceptions.