WPF Window showing up as a Win32 HwndWrapper class control


  • I have a test suite implemented using Microsoft UI Automation Framework, running on a remote machine using a test controller and test agent (2012). This machine runs Windows Server 2008.

    All tests have an initializing method that starts the application and then waits for its window to come up (using a certain Name property value). The tests run just fine when I do an isolated run, but if I run the entire suite, sometimes I notice that the element search for the window is failed or takes a really long while (circa 20-30 seconds).

    If I use UIAVerify, I can see that the window element exists in the visual tree -- only that instead of having a "Window" class name and a framework type of WPF, the class name is a bizarre string looking like this: "HwndWrapper{application.exe}guid", where application.exe is obviously my application, and guid is a random (as far as I can tell) guid that shows up after it. Also, the window normally has an AutomationId property associated with it, and in this case it's null. If I keep polling the visual tree, I see that eventually, after 2-3 minutes, it changes to the expected WPF window class object and gets an AutomationId property value.

    It also seems that this works just fine on my Windows 7 machine - is there a known bug with Windows Server 2008's support for UIA? Or can this be performance-related? (the server is significantly weaker than my local machine)

    Wednesday, August 21, 2013 8:46 PM

All replies

  • Hi Tal,

    We are facing exactly the same problem.

    Can you let us know if you were able to solve this problem?

    Monday, October 27, 2014 12:29 PM