We Keep Coding

Deadlock when writing to Console StreamWriter

Edit1: Simplified question: How do I find out what is the current (native) stack waiting on?:
# Child-SP RetAddr Call Site
00 000000bb`62e6de78 00007fff`e7b07489 ntdll!NtWriteFile+0x14
01 000000bb`62e6de80 00007fff`a6bfb526 KERNELBASE!WriteFile+0x79
02 000000bb`62e6def0 00007fff`a6b3d802 mscorlib_ni!DomainNeutralILStubClass.IL_STUB_PInvoke(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.Runtime.CompilerServices.ObjectHandleOnStack)$##6000000+0x246
03 000000bb`62e6dfd0 00007fff`a6b3d77b mscorlib_ni!System.IO.__ConsoleStream.WriteFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, Boolean)$##600166A+0x72
(without the private symbols and sources for ntdll of course :-/)
I know it's not progressing (the output it's trying to push to console never appeared and it was in this same stack for long minutes). Interestingly it shows supsend count 0:
0:019> ~19
. 19 Id: 3bac.1fd8 Suspend: 0 Teb: 000000bb`6059d000 Unfrozen
Start: clr!Thread::intermediateThreadProc (00007fff`b456cad0)
Priority: 0 Priority class: 32 Affinity: ff
Original question (and full context):
I'm investigating a dump of deadlocked application, where thread is stuck within following stack:
0:019> !clrstack
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.7.3101.0
SOS Version: 4.7.2563.0
OS Thread Id: 0x1fd8 (19)
Child SP IP Call Site
000000bb62e6df28 00007fffeb79a094 [InlinedCallFrame: 000000bb62e6df28] Microsoft.Win32.Win32Native.WriteFile(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)
000000bb62e6df28 00007fffa6bfb526 [InlinedCallFrame: 000000bb62e6df28] Microsoft.Win32.Win32Native.WriteFile(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)
000000bb62e6def0 00007fffa6bfb526 DomainNeutralILStubClass.IL_STUB_PInvoke(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)
000000bb62e6dfd0 00007fffa6b3d802 System.IO.__ConsoleStream.WriteFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, Boolean)
000000bb62e6e040 00007fffa6b3d77b System.IO.__ConsoleStream.Write(Byte[], Int32, Int32)
000000bb62e6e080 00007fffa6b3b458 System.IO.StreamWriter.Flush(Boolean, Boolean)
000000bb62e6e0e0 00007fffa6b3d727 System.IO.StreamWriter.Write(Char[], Int32, Int32)
000000bb62e6e140 00007fffa6b3d612 System.IO.TextWriter+SyncTextWriter.WriteLine(System.String)
The code resulting to this stack is writing text to TextWriter that was captured earlier as:
public static readonly TextWriter OriginalConsoleWriter = Console.Out;
Different thread in same application domain was earlier able to write to same StreamWriter (output is in concole and from log we can see that the thread progressed to other functions).
There is no other thread in same application domain reading/writing from/to console
There is a thread in different ('main') application domain that is waiting on Console.ReadLine():
Child-SP RetAddr Caller, Callee
000000bb6193e7e0 00007fffe7b079c6 KERNELBASE!ReadFile+0x76, calling ntdll!NtReadFile
000000bb6193e7f8 00007fffb4566a8f clr!SafeHandle::DangerousAddRef+0x6f, calling clr!LazyMachStateCaptureState
000000bb6193e860 00007fffa6bfb526 (MethodDesc 00007fffa6783f60 +0xc6 DomainNeutralILStubClass.IL_STUB_PInvoke(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr))
000000bb6193e8c8 00007fffa6bfb526 (MethodDesc 00007fffa6783f60 +0xc6 DomainNeutralILStubClass.IL_STUB_PInvoke(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr))
000000bb6193e940 00007fffa742779a (MethodDesc 00007fffa6898440 +0xba System.IO.__ConsoleStream.ReadFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, Boolean, Boolean, Int32 ByRef)), calling 00007fffa6aae778 (stub for Microsoft.Win32.Win32Native.ReadFile(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr))
000000bb6193e9d0 00007fffa74276a4 (MethodDesc 00007fffa6898420 +0x64 System.IO.__ConsoleStream.Read(Byte[], Int32, Int32)), calling (MethodDesc 00007fffa6898440 +0 System.IO.__ConsoleStream.ReadFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, Boolean, Boolean, Int32 ByRef))
000000bb6193ea30 00007fffa6b98024 (MethodDesc 00007fffa676cc38 +0x44 System.IO.StreamReader.ReadBuffer())
000000bb6193ea80 00007fffa6b985be (MethodDesc 00007fffa676cc50 +0x15e System.IO.StreamReader.ReadLine())
000000bb6193eae0 00007fffa75dd03c (MethodDesc 00007fffa689fc50 +0x3c System.IO.TextReader+SyncTextReader.ReadLine())
000000bb6193eb00 00007fffb4564595 clr!ThePreStub+0x55, calling clr!PreStubWorker
000000bb6193eb40 00007fffa73c17a3 (MethodDesc 00007fffa6753220 +0x23 System.Console.ReadLine())
I cannot however detect any deadlock or blocking from the managed stacks in dump, neither can the !dlk command:
0:019> !dlk
Examining SyncBlocks...
Scanning for ReaderWriterLock instances...
Scanning for holders of ReaderWriterLock locks...
Scanning for ReaderWriterLockSlim instances...
Scanning for holders of ReaderWriterLockSlim locks...
Examining CriticalSections...
No deadlocks detected.
Where/How else should I examine what could be blocking within Microsoft.Win32.Win32Native.WriteFile (ntdll!NtWriteFile) call?

This was most likely caused by quick-edit or mark/select mode of console.
When trying on my machine - breaking into simple console app that is spewing to console and currently blocked during select - I see this on top of the stack:
# Child-SP RetAddr Call Site
00 00000028`48bde818 00007fff`c33a1cbc ntdll!NtWriteFile+0xa
01 00000028`48bde820 00007fff`81c4c0c6 KERNELBASE!WriteFile+0x88
Which is very similar to top of the stack from our incident (offsets are bit moved; however it's a different OS - so that's possible; I already don't have access to the machine from incident).
This was legacy app, so we resolved it by hosting the process and redirecting input/output to host process console, that is already handling Console interaction in appropriate asynchronous way.

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 resolve high CPU usage and crash for asp.net application caused by System.Web.Handlers.TransferRequestHandler?

I have an ASP.NET application deployed on a server 4 vCPU, 10GB RAM, SSD HDD.
Looking up on NewRelic, I found the root cause to be:
System.Web.Handlers.TransferRequestHandler
I also, did an analysis using DebugDiag and the findings were:
The Performance Analysis shows that:
The Top Threads By Avg CPU was:
Thread 3428 - Microsoft.Win32.Win32Native.ReadFile(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)
All functions in these threads (excludes boiler-plate functions)
System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
Microsoft.Win32.Win32Native.ReadFile(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)
All operations
All functions in all operations (excludes boiler-plate functions)
System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
System.Threading.Thread.SleepInternal(Int32)
System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
Microsoft.Win32.Win32Native.ReadFile(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)
Please help and recommend steps for resolution.
Thanks

Mark EnableSessionState="False" on most pages or use a custom SessionState 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! :)