XAML Broke after update

Ok...this might be a stretch but we are out of ideas so I need to ask on here if anyone else has seen this craziness after a wyUpdate...

We have using wyUpdate for years and plan on using it in our new upcoming release. The only major change is we are .NET 4.6 now and using the .NET4 version now of wyUpdate.exeWe have seen this on 3 rigs so far. The user installs our full installer of build 75 and works fine for weeks. After a wyUpdate to build 76 the program is crashing and we look at the logs and we are getting XAML errors saying 30+ controls are null and other similar null ref error. If we wipe build 76 and do a full re-install then build 75 is also broken still that was just working before the update. We tried full wipes of .NET and still doesn't help. Even when building in VS on a the newly broken rig now shows these errors that was building fine minutes before the update. It's as if something happened during the wyUpdate and it torpedo'd .NET and broke it permanently.

I saw this post from Sam a while back and it sounds similar to what we are seeing."it's probably caused by invoking the UI thread before the window handle has been created."https://wyday.com/forum/t/495/autoupdater-wpf-2-6-11-unhandled-exception/#post-2471

Anyone have any ideas what might have caused this? Our only fix right now is a full-re-install of windows 8(

below is the log errors we get now on these corrupted systems.Thanks so much in advance for any info! We are close to out of ideas. 8(

Steve

---------------------LOG

[10/11/2017 6:21:54 PM] [e] WindowMain: System.NullReferenceException: Object reference not set to an instance of an object. at BaseHead.WindowMain.DrawPlayHead() at BaseHead.WindowMain.WindowMain_SizeChanged(Object sender, SizeChangedEventArgs e) at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args) at System.Windows.FrameworkElement.OnRenderSizeChanged(SizeChangedInfo sizeInfo) at System.Windows.ContextLayoutManager.fireSizeChangedEvents() at System.Windows.ContextLayoutManager.UpdateLayout() at System.Windows.Interop.HwndSource.SetLayoutSize() at System.Windows.Interop.HwndSource.set_RootVisualInternal(Visual value) at System.Windows.Window.SetRootVisual() at System.Windows.Window.SetRootVisualAndUpdateSTC() at System.Windows.Window.SetupInitialState(Double requestedTop, Double requestedLeft, Double requestedWidth, Double requestedHeight) at System.Windows.Window.CreateSourceWindow(Boolean duringShow) at System.Windows.Window.ShowHelper(Object booleanBox) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.DispatcherOperation.InvokeImpl() at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state) at System.Windows.Threading.DispatcherOperation.Invoke() at System.Windows.Threading.Dispatcher.ProcessQueue() at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) at System.Windows.Threading.DispatcherOperation.Wait(TimeSpan timeout) at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherOperation operation, CancellationToken cancellationToken, TimeSpan timeout) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg, Object[] args) at wyDay.Controls.AutomaticUpdater.auBackend_BeforeInstalling(Object sender, BeforeArgs e) at wyDay.Controls.AutomaticUpdaterBackend.InstallPendingUpdate() at wyDay.Controls.AutomaticUpdaterBackend.Initialize() at wyDay.Controls.AutomaticUpdater.System.ComponentModel.ISupportInitialize.EndInit() at MS.Internal.Xaml.Runtime.ClrObjectRuntime.InitializationGuard(XamlType xamlType, Object obj, Boolean begin) at System.Xaml.XamlObjectWriter.Logic_EndInit(ObjectWriterContext ctx) at System.Xaml.XamlObjectWriter.WriteEndObject() at System.Windows.Markup.WpfXamlLoader.TransformNodes(XamlReader xamlReader, XamlObjectWriter xamlWriter, Boolean onlyLoadOneNode, Boolean skipJournaledProperties, Boolean shouldPassLineNumberInfo, IXamlLineInfo xamlLineInfo, IXamlLineInfoConsumer xamlLineInfoConsumer, XamlContextStack`1 stack, IStyleConnector styleConnector) at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri) at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri) at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream) at BaseHead.WindowMain..ctor()

wyUpdate doesn't touch the .NET Framework. Whatever happened was a coincidence (the fact that it happened near the same time as a wyUpdate update).

I would double check your program logic. Also, try running your app on a "clean" computer (just the app, nothing else). Lastly, scan your broken computers for viruses.

Our one coders submitted a virus a long time ago on our SVN Repository that infected wyUpdate.exe but that was cleaned ages ago and we don't even use that version for this current full installer.

We now have it trapped into a corner now. We have a VMWare snapshot taken right before the update on a fresh install of Win10 and it breaks again on this 4th system directly after.

I will try those suggestions! thx

two more quick things...1. When we click "Build wyUpdate" and Open the containing folder it shows up the .NET3.5 version of wyUpdate.exeis there a setting to make it copy the NET4 version there instead?Right now I have my full installer grab the wyUpdate.net4 file and copy and rename it to wyUpdate.exe for the install package. Is that the correct way to do this?

2. Is there a .NET 4 version of wyBuild? I have to keep .NET3.5 installed still just to use this application and only this on my system 8)

thx Wyatt!and keep up the good work man!

Steve

More info on this...

If we go to our VM Snapshot and run wyUpdate.exe direct from the Install folder it updates correctly.Then if we revert our VM Snapshot and we initiate an auto-update via our application then it breaks the XAMLWhat could possibly be happening different between updating direct with wyUpdate.exe compared to updating from within the application using AutomaticUpdaterWPF.dll?

thx for any insight you have on this!

Regarding previous question...1. I figure that out. Found the option it in "Properties" menu item 8)

The automatic updater uses wyUpdate.exe. Which means the behavior should be identical (because an identical process is happening). In the AutomaticUpdater cancel the current update and restart the process. Maybe you've cached a bad update that you've released.

Lastly, always use update signing: https://wyday.com/wybuild/help/update-signing.php

thx for the reply!ok I've actually been meaning on trying the digital signing thing

I have more info that might explain this more.....I found out that Updates will actually work fine from inside BaseHead IF you force it and choose "Install Update Now" from the updater once downloaded while it's displaying "Update will be installed on next start"

BUT! once downloaded if I just quit BH and relaunch it you never see the wyUpdate window popup on next launch or look like it even tries and it breaks everything then.All our previous versions worked fine doing this. wyUpdate would just jump up first if it knew an update was already downloaded and update it before launching.Maybe it's trying to work just but quits immediately leaving BaseHead in a limbo state. seems like it

Where is the pref/setting written that tells wyUpdate.exe to run on next launchMaybe that is where the problem is. Everything is pointing to that right about now 8)

thx man!

p.s. I can also trigger automaticUpdater.InstallNow(); from inside the program and that also works fine