tags:

views:

59

answers:

2

Here's the scenario:

1: Our WPF application starts

2: The WPF application loads various user controls, including some that use the new BitmapCache feature in WPF 4

3: Hit ctrl-alt-delete or win+l or load another application which requires UAC

4: Cancel that stuff

The WPF application is now unresponsive, however it's WPF itself which is the problem. All the application logic on all the background threads is fine, and you can interact with it by pressing alt+f4, etc, but the screen never redraws

Points of note:

  • If you break into the debugger at this point there is no user code running, it's all WPF
  • Killing DWM.exe brings the application back to life
  • If we take out the BitmapCached elements, it doesn't lock up
  • I made another simple sample application which used BitmapCache, and it didn't exhibit the problem.

Help!!

A: 

Seems problem is hard to reproduce. All i can suggest is advanced debugging -

  • Ensure your stack trace browser "Shows external code" (right button menu in VS on stack trace). Then locate exact place in WPF internals where your application stuck.
  • Next step is to load pdb's for that assembly or much simpler - use .NET Reflector.
  • A lot of looking and thinking...
  • ???
  • PROFIT!

    :)

ProfyTroll
If only it were as easy as that. All the stack traces are in unmanaged win32 code, so reflector and the .net source stepping won't help :-(
Orion Edwards
finally could be in unmanaged code, no doubt. But at least it would give you some possible reasons for such behavior. Find the last trail in managed code in WPF libraries - that's how i see beginning of solution.
ProfyTroll
A: 

After much hard work, a co-worker finally managed to track this down.

Our application initially shows a logon window, then closes it, and shows a main window. We discovered a long time ago that if you do this, WPF assumes that the first window (the logon window) is the application's main window, and so it shuts down when it closes.

To mitigate this, we created a fake offscreen window (which is never shown) before any other windows. WPF then assumes this fake window is the main one - it never closes, so our app can work as desired.

For reference, the fake window looks like this:

m_mainWindow = new Window { Left = int.MaxValue, Top = int.MaxValue, Width = 1, Height = 1 };
m_mainWindow.ShowInTaskbar = false;

This was all fine. Some time later, another developer added some code to Show and Hide this fake window.

Showing the main window was what caused it.


Here's a full repro:

A: Make a new WPF app in visual studio

B: Put the following code in your App class in App.xaml.cs

public partial class App : Application
{
    Window m_mainWindow;

    public App()
    {
        m_mainWindow = new Window { Left = int.MaxValue, Top = int.MaxValue, Width = 1, Height = 1 };
        m_mainWindow.ShowInTaskbar = false;

        // Comment this line out and the problem goes away
        m_mainWindow.Show();
    }
}

C: Put at least one BitmapCached element in your MainWindow.xaml. Here's mine

<Window x:Class="LockupRepro.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid CacheMode="BitmapCache">
        <Button Content="Look a button" />
    </Grid>
</Window>
  1. Run this program (I'm on windows 7), and then press ctrl+alt+del, or bring up a UAC prompt.

You'll see the app appear to lock up as described in the question - commenting out the m_mainWindow.Show fixes it.

Update:

Upon some further investigation it's not just showing the window, it's the fact that ShowInTaskBar is set to false. If we don't set that, then showing the window no longer causes the issue.

Bizarre!

Orion Edwards