.NET application cannot start and receive XamlParseException

Question

I wrote an app that can install and work on my development PC (a Window 7).

• Development Environment: Window 7, VS2010 WPF C# with both .NET 4

Answer 1

I had a .Net 2.0 app that worked with debugging on But not in a release build(after install). I wasn't getting any logging from my Application directly, my Errors came straight from .NET. The issue was I had created my Own Program class with a static void MAIN() inside the main I had a try...catch..finally block. For some reason .NET was choking on the finally. Do you have anything like that in your program?

Answer 2

Please note that I had a similar exception:

Application: Foo.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidOperationException
   at CommonServiceLocator.ServiceLocator.get_Current()
   at Prism.Regions.RegionManager.CreateRegion(System.Windows.DependencyObject)
   at Prism.Regions.RegionManager.OnSetRegionNameCallback(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.SetValueCommon(System.Windows.DependencyProperty, System.Object, System.Windows.PropertyMetadata, Boolean, Boolean, System.Windows.OperationType, Boolean)
   at System.Windows.Baml2006.WpfMemberInvoker.SetValue(System.Object, System.Object)
   at MS.Internal.Xaml.Runtime.ClrObjectRuntime.SetValue(System.Xaml.XamlMember, System.Object, System.Object)
   at MS.Internal.Xaml.Runtime.ClrObjectRuntime.SetValue(System.Object, System.Xaml.XamlMember, System.Object)

Exception Info: System.Windows.Markup.XamlParseException
   at System.Windows.Markup.WpfXamlLoader.Load(System.Xaml.XamlReader, System.Xaml.IXamlObjectWriterFactory, Boolean, System.Object, System.Xaml.XamlObjectWriterSettings, System.Uri)
   at System.Windows.Markup.WpfXamlLoader.LoadBaml(System.Xaml.XamlReader, Boolean, System.Object, System.Xaml.Permissions.XamlAccessLevel, System.Uri)
   at System.Windows.Markup.XamlReader.LoadBaml(System.IO.Stream, System.Windows.Markup.ParserContext, System.Object, Boolean)
   at System.Windows.Application.LoadBamlStreamWithSyncInfo(System.IO.Stream, System.Windows.Markup.ParserContext)
   at System.Windows.Application.LoadComponent(System.Uri, Boolean)
   at System.Windows.Application.DoStartup()
   at System.Windows.Application.<.ctor>b__1_0(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.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 MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(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 MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, 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 System.Windows.Threading.ExceptionWrapper.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.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 Foo.App.Main()

The key part in my case above was the CommonServiceLocator.ServiceLocator.get_Current(). My application did not use ServiceLocator anywhere; however, it appears that it was being used by a NuGet package I had installed.

I solved the problem by performing this in the NuGet Package Manage console for my main app project:

PM> Install-Package CommonServiceLocator -Version 2.0.5

Answer 3

Although you were targetting .NET 3.5 your client hat .NET 4 installed and used it. The string

Framework Version: v4.0.30319

does tell me this. To force your client to actually use .NET 3.5 you should add an App.config to your application and add:

<configuration>
   <startup>
      <supportedRuntime version="v2.0.50727"/>
   </startup>
</configuration>

It could be that you are getting an exception because .NET 4 treats your XAML in a different way. Did you try to let your application run under .NET 4? If you have no App.config supplied you did test your application with .NET Framework 4 anyway although you did target .NET Framework 3.5. If your client is nice enough you can let him create a dump file so you have an easy way to debug it directly. Download Procdump from the SysInternals tool suite and send it along with your application to your client. The let him execute

procdump -ma -e -t -x foo.exe %temp%\dump.dmp

This will generate a full process dump for every unhandled exception and another one when the process terminates into the %TEMP% directory. Visual Studio 2010 has gotten much better dump analysis support so you should be able to analyze it within Visual Studio 2010. If that does not help you can download Windbg (32 bit here), load the dump and type

!analyze -v

to see what the last exception was. That should do the trick. There may be issues with the managed extensions to load the right debugging dll (sos.dll for .NET 2,3,3.5, and clr.dll for .NET 4) but there are plenty of tutorials online how to do it. Besides this I would recommend to add exception handlers into your application so you get a nice log file when your application does terminate in an unexpected way.

If the output did not lead to the right stack you shold use !ClrStack and !Threads to find out which threads have exceptions on their stack.

Answer 4

I've seen this happen on machines where the installation of .NET 3.5/4 had failed/not successfully completed. However, this is also highly unlikely.

You should try to install remote debugging on the machine (fairly easy process) and then setting the remote machine as the target in Visual Studio, run the program in debug mode. The program will then launch on the remote machine and you will get the full error within Visual Studio.

Answer 5

You can remote debug. Basically this is done by installing the remote debug server on the target machine, then attach to it from your visual studio when you start the application. Some more info can be found here : http://msdn.microsoft.com/en-us/library/bt727f1t.aspx and there's a somewhat elderly tutorial here : http://www.cprogramming.com/tutorial/visual_studio_remote_debugging.html

Please note that you must deploy with debug symbols (pdbs) and the software debugged must be in the same version that your code is in.

Answer 6

Start commenting out lines of code and entire classes/methods from your code until you get it working (Or start by commenting out everything). Then slowly start introducing lines of code and method calls etc. Until it breaks. This should give you an idea of any particular code/class or reference that is causing the problem. This is admittedly a tedious method, but at the same time, fairly mechanical and within an hour or so you should have a fairly good idea of culprit.