Why do I get Serilog SelfLog error while using Serilog logging? - c#

I have an interesting error while using Serilog SelfLog. The error is:
Application: XXX.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions, System.String, Boolean, Boolean, Boolean)
at System.IO.StreamWriter.CreateFile(System.String, Boolean, Boolean)
at System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding, Int32, Boolean)
at System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding)
at System.IO.File.InternalAppendAllText(System.String, System.String, System.Text.Encoding)
at Serilog.Debugging.SelfLog.WriteLine(System.String, System.Object, System.Object, System.Object)
at Serilog.Sinks.PeriodicBatching.PeriodicBatchingSink+<OnTick>d__16.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
at Serilog.Sinks.PeriodicBatching.PortableTimer+<OnTick>d__8.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
I do not have an idea what happens. I have .Net framework 4.6.1, Serilog version 2.9.0 and I cannot produce the error again.
Please Can you help me to describe the error? Why did I get the error? Do you know any solutions for this error?
I use libraries below:
Serilog v2.9.0
Serilog.Enrichers.Context v2.4.0
Serilog.Extensions.Logging v2.0.4
Serilog.Settings.AppSettings v2.2.2
Serilog.Sinks.Console v3.1.1
Serilog.Sinks.File v4.1.0
Serilog.Sinks.Http v5.2.1
Serilog.Sinks.PeriodicBatching v2.2.0
Serilog.Sinks.RollingFile v3.3.0
Microsoft.Extensions.Logging.Abstractions v1.0.0
EDIT:
My app conf here:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="serilog:minimum-level" value="Verbose" />
<add key="serilog:using:Console" value="Serilog.Sinks.Console" />
<add key="serilog:write-to:Console" />
<add key="serilog:using:Http" value="Serilog.Sinks.Http" />
<add key="serilog:write-to:Http.requestUri" value="http://log.XXX.com:8080/TestEngine" />
<add key="serilog:write-to:Http.batchPostingLimit" value="1" />
<add key="serilog:write-to:Http.batchFormatter" value="Serilog.Sinks.Http.BatchFormatters.ArrayBatchFormatter, Serilog.Sinks.Http" />
<add key="serilog:enrich:with-property:application" value="TestEngine" />
</appSettings>
<startup>
...
Serilog integration here:
var config = new LoggerConfiguration()
.Enrich.FromLogContext()
.Enrich.WithMachineName()
.Enrich.WithUserName()
.ReadFrom.AppSettings();
if (CustomLogContext == null)
{
CustomLogContext = new Dictionary<string, object>();
}
foreach (var logContext in CustomLogContext)
{
config.Enrich.WithProperty(logContext.Key, logContext.Value);
}
if (!string.IsNullOrEmpty(CustomLogFileFullName))
{
config = config.WriteTo.File($"{CustomLogFileFullName}");
}
Serilog.Log.Logger = config.CreateLogger();
Serilog.Debugging.SelfLog.Enable(msg => File.AppendAllText("internallog.log", msg, Encoding.UTF8));
ILoggerProvider loggerProvider = new SerilogLoggerProvider(Serilog.Log.Logger);
_logger = loggerProvider.CreateLogger("XXX.Logging.Serilog");
SOLUTION:
As #RubenBartelink says, if you use Selflog but you use custom log files, you take a few risks. Because Serilog may not write a custom file and may be Serilog throw an IO exception. This problem does not belong to Serilog. The problem is actually File.AppendAlltext operation. The solution is as follows:
Serilog.Debugging.SelfLog.Enable(msg =>
{
try
{
File.AppendAllText("internallog.log", msg, Encoding.UTF8);
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
});

As alluded to in the comment from #Daniel A. White, you are doing a risky thing -- trying to write to a file, in a handler that's provided on an "if all else fails" basis. Some examples:
if the disk is full and the File Logger can't write (File sinks dont necessarily do that, but if they wanted to communicate failure, it would be via the SelfLog)
if a message string is malformed (Serilog logging calls will never throw; this is based on a fundamental tenet in the wiki about the logging not being important enough to stop a working app from working)
While the Serilog debugging and diagnostics Wiki page currently shows an example of writing to a file, that's simply not the nature of the contract -- it must not fail.
Hence, if you actually want to emit the SelfLog to a file, you will need to add a try/catch and swallow the exception in the handler.
I would say its pretty questionable value to have a file as a backup when the File Sink is your primary output. This is doubly the case as you don't have any mechanism to ensure it gets trimmed (imagine you had a tight loop logging with a malformed message string - it would fill your disk eventually).
I personally have handled this tradeoff by echoing the SelfLog to my Console Sink (which logging won't throw, per the above) on the basis that the operating environment (think Kubernetes) can be trusted to capture it, or alert.

Related

VS 2013 Crash When Using JSON Deserialize Method

I've created a C# ASP.NET method which simply takes a string property containing JSON, both inside the same class. My issue is that whenever I type the .Deserialize method (the commented line) Visual Studio 2013 crashes with an "Unhandled Exception" in event logs.
public object JSONAsObject()
{
object obj = new object();
JavaScriptSerializer js = new JavaScriptSerializer();
// obj = js.Deserialize<object>(this._json);
return obj;
}
If I write the line in comments (as above) then remove the comments there's no problem so the issue appears to be with Intellisense or the way I'm writing the code - anyone have any ideas?
Crash log
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentNullException
Stack:
at System.Text.RegularExpressions.Regex.Escape(System.String)
at Microsoft.OneCode.Utilities.UserControl.CodeSnippetsTextBox.UpdateRegex()
at Microsoft.OneCode.Utilities.UserControl.CodeSnippetsTextBox.OnMyWorkCollectionChanged(System.Object, System.Collections.Specialized.NotifyCollectionChangedEventArgs)
at System.Collections.ObjectModel.ObservableCollection`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].OnCollectionChanged(System.Collections.Specialized.NotifyCollectionChangedEventArgs)
at System.Collections.ObjectModel.ObservableCollection`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].InsertItem(Int32, System.__Canon)
at System.Collections.ObjectModel.Collection`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Add(System.__Canon)
at Microsoft.OneCode.IntellisensePresenter.ViewModel.IntellisenseViewModel.UpdateCodeSnippets(System.Collections.Generic.IEnumerable`1<Microsoft.OneCode.DataModel.CodeSearchResult>)
at Microsoft.OneCode.IntellisensePresenter.ViewModel.IntellisenseViewModel+<>c__DisplayClass5.<SearchCode>b__2()
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.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
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.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
Please let me know if this needs to go onto SuperUser.
Edit 1:
Just to confirm this issue occurs during development, not at runtime. VS crashes when I am typing the code.
Edit 2:
This issue only occurs with this particular line. The system I'm working with is massive and I've never seen the problem before.
Edit 3:
Same issue in a brand new project - potentially a bug in VS 2013 but I don't know what's throwing the exception in the first place.
As #Jehof suggested in the comments I disabled all of my VS 2013 extensions, which fixed the problem. Enabling each extension one by one showed that the Bing Developer Assistant was causing the problem. There was an update which hasn't installed - installing this update fixed the problem.
To anyone else with such a problem, ensure VS and all extensions are fully updated.
Visual Studio keeps crashing Visual Studio when working with TBS and Angular JS.
System.NullReferenceException was unhandled
Additional information: Object reference not set to an instance of an object.
IntelliSense uses large amounts of memory on medium/large projects which can result in crashes and instability - you can turn off completions in Tools/Options/Text Editor/Node.js/Statement completion/Auto list members to avoid this (recommended).
You can not use "object", you must use a type.
Deserialize<T>()
, where T is a type, cannot be "object"

How to diagnose InnerException content on deployed (client machine) in unknown thread?

I've got a C# application running over Microsoft .NET (4.x), and on my 2 machines my application installs and run well.
On other machines (client machines), I can't debug : no visual studio, no symbol no debug mode.
But, they crash.
I have that in the windows event log:
例外情報:System.Reflection.TargetInvocationException
スタック:
場所 System.RuntimeTypeHandle.CreateInstance(System.RuntimeType, Boolean, Boolean, Boolean ByRef, System.RuntimeMethodHandleInternal ByRef, Boolean ByRef)
場所 System.RuntimeType.CreateInstanceSlow(Boolean, Boolean, Boolean, System.Threading.StackCrawlMark ByRef)
場所 System.RuntimeType.CreateInstanceDefaultCtor(Boolean, Boolean, Boolean, System.Threading.StackCrawlMark ByRef)
場所 System.Activator.CreateInstance(System.Type, Boolean)
場所 System.Activator.CreateInstance(System.Type)
場所 DevExpress.XtraSplashScreen.ThreadManagerBase.CreateForm()
場所 DevExpress.XtraSplashScreen.ThreadManagerBase.ThreadEntryPoint(System.Object)
場所 System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
場所 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
場所 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
場所 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
場所 System.Threading.ThreadHelper.ThreadStart(System.Object)
Normally, I have a crash interceptor that displays the call stack within the software itself, but it works only on the main thread.
Here my problem is, this thread looks like it is spawned by DevExpress (GUI framework) and I don't control this thread, and I can't code a crash catcher.
I want to print out the "InnerException" content of the TargetInvocationException to see more details.
How would you do that ?
You should add logging to your application and log the entire exception yourself. Typically, calling ToString() prints the entire exception message, call stack and the inner exceptions as well. There are several logging libraries like log4net and NLog, so you don't have to create the logging infrastructure yourself.
Depending on your application type (WinForms, WPF, Web), you can add a handler to the appropriate unhandled exception event and log any uncaught exceptions there. Check these samples for WinForms, WPF and ASP.NET
In WinForms you should set the exception handlers before creating the main form of the application:
public static void Main(string[] args)
{
Application.ThreadException +=
new ThreadExceptionEventHandler(myThreadExceptionHandler);
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(myUnhandledExceptionHandler);
Application.Run(new MyStartForm());
}
while in WPF you need to catch the App's DispatcherUnhandledException event:
public partial class App : Application
{
void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
//...
}
}
As mentioned in the comments, DebugDiag is an excellent tool for production debugging.
You can set it to take a dump when a TargetInvocationException occurs. Later, you may also use it to diagnose the stacktrace, or if you need a more advanced tool, look into WinDBG with the managed SOS module.

c# windows application launches external exe's fine in visual studio but not when installed

I have a program which is a authoring tool for making courses. I decided to create a screen recording feature for it using camstudio. The code I used to launch the exe is:
Process process = new Process();
process.StartInfo.FileName = "Recorder.exe";
process.StartInfo.Arguments = "";
process.Start();
When I am running the program in visual studio and step through the code it works fine and launches the recorder.exe with no errors. BUT when I make an installer for the project in visual studio 2010 and install the program, the program crashes when I press the button which should launch the recorder.exe.
I checked the windows error log and here is what it told me:
Application: Perform.exe Framework Version: v4.0.30319 Description:
The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.Win32Exception Stack: at
System.Diagnostics.Process.StartWithShellExecuteEx(System.Diagnostics.ProcessStartInfo)
at System.Diagnostics.Process.Start() at
P2Designer.Window1.scriptUpdatePerform(System.Object,
System.Windows.RoutedEventArgs) at
System.Windows.RoutedEventHandlerInfo.InvokeHandler(System.Object,
System.Windows.RoutedEventArgs) at
System.Windows.EventRoute.InvokeHandlersImpl(System.Object,
System.Windows.RoutedEventArgs, Boolean) at
System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject,
System.Windows.RoutedEventArgs) at
System.Windows.UIElement.RaiseEvent(System.Windows.RoutedEventArgs) at
DevComponents.WpfRibbon.ButtonDropDown.OnClick() at
DevComponents.WpfRibbon.ButtonDropDown.x984587de9d70aaba(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.RunInternal(System.Threading.ExecutionContext,
System.Threading.ContextCallback, System.Object, Boolean) 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.LegacyInvokeImpl(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.Threading.Dispatcher.Run() at
System.Windows.Application.RunDispatcher(System.Object) at
System.Windows.Application.RunInternal(System.Windows.Window) at
System.Windows.Application.Run(System.Windows.Window) at
System.Windows.Application.Run() at P2Designer.App.Main()
Found a similar unanswered question on here: Why i'm getting a win32exception once i'm starting the Process?
If more information is need please let me know and I'll provide as much as I can. I have seen similar questions on here and other forums but none have given me the answer.
Thanks, Jim
(Per Josh Gallagher's suggestion, reposting comment as answer)
That is likely an issue with current working directory (cwd). IIRC, VS actually sets cwd to the output folder when launching your exe in debug. However, in read world, cwd really depends on how exe is launched and does not necessarily point to the same folder where your target exe is.
You can actually test it easily by simply writing the value of Environment.CurrentWorkingDirectory (or something like that) and see what it points to. alternatively try to hardcode full path for now while troubleshooting. Either way, my money are on the fact that your context for execution is in wrong dir.
Wrap your code in
try
{
Process process = new Process();
process.StartInfo.FileName = "Recorder.exe";
process.StartInfo.Arguments = "";
process.Start();
}
catch(Exception e)
{
//Log using your logger the full error message.
}
This will give you indication of what's faulting your program. Difference between success in VS and failure in real world is likely some context such as current working directory. But at least this will give you information as to what is the nature of the error that causes it to crash.

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

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()
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.
For me there was an overlay that would show some hardware info that was causing the error. Once I turned the overlay off (ASUS GPUTWEAK II), it solved the issue, make sure that you don't have 3rd party programs interfering with your own! :)

AccessViolationException on VISTA only

I have a WPF/Winforms application that works perfectly fine on XP, as well as Win 7. But on Vista, ONLY sometimes - may be 20-30% of the time I see this:
Any help is much appreciated
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
at MS.Win32.PresentationCore.UnsafeNativeMethods+WICImagingFactory.CreateDecoderFromStream(IntPtr, IntPtr, System.Guid ByRef, UInt32, IntPtr ByRef)
at System.Windows.Media.Imaging.BitmapDecoder.SetupDecoderFromUriOrStream(System.Uri, System.IO.Stream, System.Windows.Media.Imaging.BitmapCacheOption, System.Guid ByRef, Boolean ByRef, System.IO.Stream ByRef, System.IO.UnmanagedMemoryStream ByRef, Microsoft.Win32.SafeHandles.SafeFileHandle ByRef)
at System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(System.Uri, System.Uri, System.IO.Stream, System.Windows.Media.Imaging.BitmapCreateOptions, System.Windows.Media.Imaging.BitmapCacheOption, System.Net.Cache.RequestCachePolicy, Boolean)
at System.Windows.Media.Imaging.BitmapImage.FinalizeCreation()
at System.Windows.Media.Imaging.BitmapImage.EndInit()
at System.Windows.Forms.Integration.Convert.ToSystemWindowsMediaImagingBitmapImage(System.Drawing.Image)
at System.Windows.Forms.Integration.ElementHostPropertyMap.UpdateBackgroundImage(System.Windows.Forms.Integration.ElementHost)
at System.Windows.Forms.Integration.ElementHostPropertyMap.BackgroundPropertyTranslator(System.Object, System.String, System.Object)
at System.Windows.Forms.Integration.PropertyMap.RunTranslator(System.Windows.Forms.Integration.PropertyTranslator, System.Object, System.String, System.Object)
at System.Windows.Forms.Integration.PropertyMap.OnPropertyChanged(System.Object, System.String, System.Object)
at System.Windows.Forms.Integration.ElementHost.OnPropertyChanged(System.String, System.Object)
at System.Windows.Forms.Integration.ElementHost.UpdateBackground()
at System.Windows.Forms.Integration.ElementHost.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.OnParentVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.OnParentVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.OnParentVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.Form.OnVisibleChanged(System.EventArgs)
at System.Windows.Forms.Control.SetVisibleCore(Boolean)
at System.Windows.Forms.Form.SetVisibleCore(Boolean)
at System.Windows.Forms.Control.set_Visible(Boolean)
at WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetVisible()
at WeifenLuo.WinFormsUI.Docking.DockPane.set_ActiveContent(WeifenLuo.WinFormsUI.Docking.IDockContent)
at WeifenLuo.WinFormsUI.Docking.DockContentHandler.Activate()
at WeifenLuo.WinFormsUI.Docking.DockContentHandler.Show(WeifenLuo.WinFormsUI.Docking.DockPanel, WeifenLuo.WinFormsUI.Docking.DockState)
at WeifenLuo.WinFormsUI.Docking.DockContent.Show(WeifenLuo.WinFormsUI.Docking.DockPanel, WeifenLuo.WinFormsUI.Docking.DockState)
at MyApp.MainForm.OpenVisualSqlDesigner(Boolean, ToolkitUI.Model.Table)
at MyApp.Commands.TableCommands.VisualDesignerCommand.Execute()
at MyApp.Commands.CommandToolstripMenuItem.OnClick(System.EventArgs)
at System.Windows.Forms.ToolStripItem.HandleClick(System.EventArgs)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(System.Windows.Forms.MouseEventArgs)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(System.EventArgs, System.Windows.Forms.ToolStripItemEventType)
at System.Windows.Forms.ToolStripItem.FireEvent(System.EventArgs, System.Windows.Forms.ToolStripItemEventType)
at System.Windows.Forms.ToolStrip.OnMouseUp(System.Windows.Forms.MouseEventArgs)
at System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.ScrollableControl.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.ToolStrip.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
It looks like this exception occurred when the application tried to create a BitmapImage, could it be that your system blocks or locks access to a specific file that is needed to load the image from?
WIC, what you see on the top of the stack trace, is the underlying imaging library for WPF. It is a COM component, written in C++. It is not unusual for unmanaged code to bomb with AccessViolation. You could possibly wring some more info out of the stack trace by enabling unmanaged code debugging and enabling the Microsoft Symbol Server.
Nevertheless, the odds are not good to put any kind of dent in this problem. The only knobs you can tweak is the image itself, it might be corrupt in a way that makes the code bomb. And make sure that service pack 1 is installed on the machine. Beyond this, you'll need the help from Microsoft Support. They'll need a minidump of the crashing program and the image that causes the trouble.
Thanks a lot - and very helpful. Turning on unmanaged code debugging led me to the problem being "This indicates memory is corrupt elsewhere". Since I didnt too much finagling with memory, I knew it must have been one of the outside dlls that were being referneced. IT turns out that ICSharpCode.TextEditor.dll is the root of the issue, and updating to the latest version of it fixed it!!!

Categories