WPF Dispatcher - Suddenly "stuck" and not processing actions until I press a key

6
votes

We're experiencing a very weird issue in our WPF app.

On startup our app fires off some service requests. Then when the window is loaded is unresponsive until we press a key. CPU usage is 0%.

It looks like a UI deadlock although not a true one - we can resize it and move it. When attaching the debugger, we see the main thread is on Win32.UnsafeNativeMethods.GetMessageW - it's not waiting on a lock as you normally see in this type of issues.

Then if we press a key, it continues processing actions we have passed in to Dispatcher.BeginInvoke.

This happens on both debug and release builds but only when it's built by the MSBuild tool. If I build the app on my PC in both VS2010 and VS2012 - both targeting .NET 4.0 - the issue never happens.

Any ideas as to how identify what's preventing the Dispatcher from executing actions till a key is pressed?

Regards.

P.S - See below the UI thread stack trace.

WindowsBase.dll!MS.Win32.UnsafeNativeMethods.GetMessageW(ref System.Windows.Interop.MSG msg, System.Runtime.InteropServices.HandleRef hWnd, int uMsgFilterMin, int uMsgFilterMax) + 0x14 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.GetMessage(ref System.Windows.Interop.MSG msg, System.IntPtr hwnd, int minMessage, int maxMessage) + 0x80 bytes WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame frame) + 0x75 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame frame) + 0x49 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.Run() + 0x4b bytes
PresentationFramework.dll!System.Windows.Application.RunDispatcher(object ignore) + 0x17 bytes
PresentationFramework.dll!System.Windows.Application.RunInternal(System.Windows.Window window) + 0x6f bytes PresentationFramework.dll!System.Windows.Application.Run(System.Windows.Window window) + 0x26 bytes PresentationFramework.dll!System.Windows.Application.Run() + 0x1b bytes MyApp.App.Main() Line 50 + 0xa bytes

1
wpfmultithreadingdeadlockdispatcher
I've been doing further digging - seems to be related to the Component One license. The build script blanks it out because the license is not installed on the build servers. So if I blank it out locally, I do get the same issue. If I don't, then it works fine. So looks like I need to fix my local C1 license. What I don't understand is why I don't see the license popup instead of this awkward freeze issue – Alberto

1 Answers

1
votes

This is a long shot, but, it may be due to possible bug in .Net 4.0 that is fixed in .Net 4.5. Are you testing on the Jenkins build machine as well as compiling?

I have had a few incidents where problems like this have occurred (everything compiles on both Dev and Build machine, but run-time exceptions happen in core framework on test machine that do not occur on Dev machine).

In these instances, the source of the problem has been that whilst targeting .Net 4.0, the assemblies for .Net 4.0 get overwritten when .Net 4.5/4.5.1 is installed (as part of VS2012), so whilst the source code is identical, the behaviour has changed and therefore, everything seems OK on a machine with VS2012, but not on a machine with only VS2010 and/or only.Net 4.0.

As a suggestion, try building using VS2012 (still targeting .Net 4.0) but then running the output application on a machine with just .Net 4.0 and then on a machine with .Net 4.5 installed. If everything is OK on the .Net 4.5 machine but not the .Net 4.0 machine, this is likely to be the problem.

As I say, this is a stab in the dark and there may be a genuine programmatic problem there, but it is worth looking at as a starting point.

This, of course, is fine if you are allowed to install .Net 4.5 with your application. If not, you may have to find a programmatic work around for the problem.