Question

我想解决的一个大问题是确定为什么在我们的托管应用程序中，我们不时会收到访问冲突异常（0xc0000005）。最近，在一个完全不同的应用程序中，我们开始收到一个NullReference异常（现在是一个已知的bug），但它后面跟着一个（0xc0000005）错误。我想知道这是正常行为还是与我们的大问题有关。

访问冲突异常（第二次）

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异常（第1个）

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

是的，这是正常的。在Windows中没有“空引用异常”这样的东西。处理器通过一般保护故障陷阱报告这种指针故障，这会在操作系统中生成访问冲突异常。异常代码0xc0000005。

Windows通过始终保留底部64KB来设置进程的虚拟内存，从地址0开始取消映射。特别是为了检测指针错误，它们在编程中非常常见。因此，NULL指针将始终使处理器故障跳闸。以及大于0的地址，当程序试图通过空指针访问对象的字段时生成。

CLR拦截本机访问冲突异常并查看导致异常的地址。如果它位于该64KB地址范围内，则会引发System.NullReferenceException。如果不是那么它会引发System.AccessViolationException。

顶部片段是Windows生成的诊断，CLR的底部。最上面的一个只显示本机异常代码，Windows对托管异常一无所知。

Answer 2

对我来说，有一个覆盖层会显示一些导致错误的硬件信息。一旦我关闭叠加层（ASUS GPUTWEAK II），它就解决了这个问题，请确保您没有第三方程序干扰您自己的程序！：）

在NullReferenceexception之后接收访问冲突异常（0xc0000005）是否正常

2 个答案: