Our application using the AutomaticUpdater has a problem depending on how the update is performed. When I manually activate the AutomaticUpdater to perform the download, then I click the AU to "Restart Now" or "Update Now" (whichever that is), the application shuts down, wyUpdate does its thing, and the application starts back up with no problem.
However, some of our users have forcibly checked an update through the menu and seen the "Update will be installed on next restart" icon. Instead of clicking the icon and choosing "Restart Now" like I have, they close the application and restart it from its shortcut.
What's happening is that the splash screen finishes and a separate form is shown (depending on how the application was launched), but the main form containing the AU control seems to never finish Show()ing.
I've finally reproduced the issue and have used Visual Studio to attach to the process, and here's the stack trace while the application is hanging:
[In a sleep, wait, or join] > mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool exitContext) + 0x2f bytes mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) + 0x25 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle waitHandle = {System.Threading.ManualResetEvent}) + 0x77 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control caller, System.Delegate method, object[] args, bool synchronous) + 0x393 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method, object[] args) + 0x50 bytes AutomaticUpdater.dll!wyDay.Controls.UpdateHelper.pipeClient_MessageReceived(byte[] message) + 0x7a bytes AutomaticUpdater.dll!wyDay.Controls.PipeClient.Read() + 0x159 bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x66 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes
The main thread seems to be waiting at the end of the OnLoad event handler.
Once this state has been reached, the user has to shut down the application through the task manager. Then if they launch through a shortcut again, it hangs in the same spot again.
I see an instance of InstantUpdate.exe sitting in the task manager. When I start the application, another instance starts briefly and then shuts down. Killing that instance and then starting my application leaves InstantUpdate.exe running, so that's probably part of the issue.
If I kill my application, and leave InstantUpdate.exe running (as a customer would do), then run wyUpdate.exe directly, I am informed that the application updated successfully, but I observe the same behavior as before. The process's stack trace is identical to before.
Again, to reproduce the issue on my computer (XP, .NET 3.5, wy* 2.5.23):
* Start application* Menu -> Check for updates* AU -> Download and install now* AU -> Info icon saying download will be installed -- do not click, but instead manually close program* Start application manually -- application hangs on Form.Show() or Application.Run(form).
Of course, creating a minimal application to demonstrate this behavior, ends up working correctly. I'm not sure what we can do to reproduce this, short of sending you the full application.
To fix this, I found two options:
1. Delete both %appdata%/wyUpdate AU and ~/wc and use the integrated AU control, taking care to restart using the icon.2. Delete just %appdata%/wyUpdate AU and I can run wyUpdate.exe (manually this time).
Obviously this is not an acceptable workaround to ask a customer to perform -- is there possibly another approach? Or maybe I'm doing something obviously wrong in integrating the AU control?
