Bug: WPF Applications Freezing at Window.Show()
My new tablet suffers from a rare disease that I am going to refer to as Paul’s Disease. If the tablet is plugged into an external monitor, and that monitor is set as the only display surface (i.e., the tablet screen is disabled) and I reboot (or, as is usually the case, something crashes) the machine boots up thinking that the pen input isn’t available because the screen is disabled.
This in itself is annoying, because even if I switch back to the tablet screen (or undock from the docking station), I need to reboot before it figures out that the pen is available.
I got quite the scare the other day because of this bug. After booting up with only the external display configured, I tried to run a WPF application. I hit F5 in Visual Studio, but nothing appeared. Nothing ran.
I set a breakpoint in the constructor of the main window, and noted that the window was indeed being instantiated, it just wasn’t being shown. Other applications like XAMLPad and the Vista Sniping tool which use WPF also wouldn’t run - I could see them in the Processes tab in Task Manager and they were using CPU cycles and memory, but I couldn’t see them on screen. Windows Forms applications worked fine.
Worried something was really broken, I rebooted a few times, uninstalled all recent Windows Updates, begged the machine to just work for a change (hey, someday it will listen 
), ran a virus scan, and uninstalled/reinstalled .NET 3.0 (I would have done a “repair”, but since you can only install .NET 3.0 as part of Vista’s Add/Remove Windows Components feature, I had to remove it and add it again). They still wouldn’t run.
In desperation, I created a new WPF application and set a breakpoint in the Application_Startup event where I was creating and showing a Window, and stepped right up until a call to Window.Show(). When I executed that line, the application froze indefinately. Hitting “Pause” in the debugger brought up the call stack, and I could see that the last method call had something to do with locking the thread while waiting for Pen input (the method name had something to do with “Pen”, and the call after had something to do with a WaitHandle).
After unplugging the external monitor and then rebooting, my WPF applications ran normally.
Filed under: WPF
I’ve posed a bug report here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=270585
Thanks for posting the bug on Connect! We will take a look and contact if you if we need more information.
Hi Paul,
When the bug repros, what does your display setting look like? Is your external monitor shown as “display2″? Is “display1″ disabled?
One more question, what’s the manufacture and model of your tablet pc? What version display driver are you using?
I have a hypothesis what’s going on but I need more information to verify.
Sorry for the long list of questions.
Hi xiao,
When this happens, Vista shows the external monitor as “Display 1″ (which is incorrect) and the internal monitor as “Display 2″ (also incorrect). Either of the displays will be disabled depending on which monitor I tell it to enable, but the numbers are always wrong (this appears to be a bug in Vista).
The model is the Fujitsu T4215: http://www.tegatech.com.au/products/digitizers/Fujitsu_T4215_with_Vista.htm
The driver is “Mobile Intel(R) 945GM Express Chipset Family”, version “7.14.10.1147″, published on 12/12/2006. It’s signed by the “microsoft windows hardware compatibility publisher”.
Hope that helps,
Paul