Question

The following program locks up reproducibly whenever the user changes the keyboard layout via a key combination. It does not lock up if the keyboard layout is changed via the tray applet. It does not lock up when changing the layout to English. It does not lock up if the Task never executes.

XAML:

<StackPanel>
    <TextBox></TextBox>
    <Button Click="Button_Click">Click me</Button>
</StackPanel>

C#:

private void Button_Click(object sender, RoutedEventArgs e)
{
    Task.Factory.StartNew(() =>
    {
        var visual = new DrawingVisual();
        using (var context = visual.RenderOpen())
        {
        }
    });
}

Before the button click, I can switch keyboard layouts as I please. After the click the program locks up on the first attempt to switch layouts.

Importantly, this bug only occurs if the layouts are switched via Alt+Shift+2 or Ctrl+Shift+2 (and 3, but not 1).

It’s way, way too late to avoid the use of DrawingVisual on background threads. This has become an integral, core feature of the product. Any ideas for how to work around this are very welcome.

This bug reproduces on .NET 4.0, Win7 32-bit and 64-bit.

Bounty: this bug affects few people in terms of percentage, but those it does affect will constantly cause the lock-up (with the corresponding data loss) every time they habitually change the keyboard layout via the shortcut. I’d like a work-around which does not change the fact that some visuals are rendered on a separate thread.

Answer 1

Official Microsoft answer:

This issue will no[t] be addressed in the next release of WPF. -WPF Team.

I’m guessing they’re all too busy with WinRT and WPF is on the back burner.