The Solution
It's clear that the error message was triggered by the AsynchronousThreadAbort MDA along with CLR; at the moment your code attempted to asynchronously call
Abort() from the main thread to another, worker thread that executed
ExecuteSplashScreen().
Note that this dialog box has a variation: Its appearance depends on whether you've checked a box in the project's properties. In Properties, go to the Debug tab. Is "Enable unmanaged code debugging" checked? When this box is checked, it changes your dialog box;s title to "Microsoft Visual Studio" and shows two buttons: "Break" and "Continue." On a 64-bit machine, you cannot do mixed mode debugging.
To fix this, you could add a try-catch statement to the ExecuteSplashScreen() method and include all its code in the try block. But when you run the application again and close the MDA's dialog box, it throws another exception:
Unable to evaluate expression because the code is optimized
or a native frame is on top of the call stack.
So, it does not matter whether you include the try-catch statement or not. Including the try-catch statement ends the thread because its function ends. Without the try-catch statement, the thread terminates because it cannot continue execution after an unhandled exception.
In this particular case, even though the thread terminates at an unsafe checkpoint at an unpredictable moment, it doesn't cause problems. The goal of the Abort() call is to end the thread that's done its work and is no longer needed by the application. Though it's against good practice to unintentionally use exceptions for "normal" execution path, in this example there is no consensus on terminating the thread with the ThreadAbortException exception.
Alternative Solutions
- MSDN suggests using a common property that signals the target thread and requests an interrupt. The target thread then checks for requests in safe checkpoints and ends gracefully.
- You could add an invisible button to the splash screen and initiate a Click event that closes the splash screen window. The following XAML example shows mix of code with markup:
<Window x:Class=”SS.SplashScreen” Name=”myName”
. . .
<Grid Name=”myGridName”>
. . .
<Button
Name=”buttonClick” Width=”0” Height=”0” Visibility=”Hidden”
Click=”OnClickButton”>
ButtonToCloseSplashScreen
</Button>
</Grid>
. . .
<x:Code>
<![CDATA[
void OnClickButton(object sender, RoutedEventArgs e) { Close(); }
]]>
</Window>
Instead of calling Abort(), this code simulates a click event for the button by using classes from the WPF UI Automation namespace. The following code snippet shows how:
AutomationElement applWindow = AutomationElement.RootElement.FindFirst(
TreeScope.Children, new PropertyCondition(
AutomationElement.AutomationProperty, “myName”);
AutomationElement btn = applWindow.FindFirst(
TreeScope.Descendants, new PropertyCondition(
AutomationElement.NameProperty, “buttonClick”);
InvokePattern btnInvokePattern = btn.GetCurrentPattern
(InvokePattern.Pattern) as InvokePattern;
btnInvokePattern.Invoke();
Of course, you'll need references to UIAutomationClient and UIAutomationTypes, which you can obtain from their corresponding DLLs located under c:\Program Files\Reference Assemblies\Microsoft\Framework\v.3.0.