Search code examples
wpfui-automationinspectmicrosoft-ui-automation

Why does Inspect.exe hang frequently and inconsistently display AutomationId?

I'm trying to use MS UI Automation to test a WPF application, and am using the Inspect Object tool (inspect.exe) included with the Windows SDK to look up the AutomationId property on certain elements.

Inspect is behaving very strangely for me:

  • If I close all applications and start the WPF application and Inspect, inspect is able to see the AutomationId property for various UI elements. Elements which do not have an AutomationId simply show two quotation marks denoting an empty string ("").

  • After I perform a few actions in the WPF application, inspect.exe hangs and I have to kill it and restart it. Even though the machine's CPU and RAM utilization are around 50% or less, I've tried waiting several minutes--possibly close to 20 or 30 mins on a couple occasions--to no avail.

  • After restarting, inspect.exe can no longer find an AutomationId for any UI element, even those which did have them previously. What's more, the property is completely missing when hovering the mouse over the WPF application--it is no longer listed at all, not even with an empty string value.
  • If I move the mouse to another screen (specifically, to another computer, using Mouse Without Borders), the AutomationId property reappears with a value of "FormDot"
  • If I restart only inspect additional times while the WPF application is still running, inspect still behaves the same as after the first restart.
  • If I restart only the WPF app while inspect is still running, inspect still behaves the same as after its first restart.
  • If I close both inspect and the WPF app, then start inspect, then start the WPF app, everything works correctly for a while and inspect finds the AutomationId on a few elements in the WPF app...up until the point at which inspect hangs again.

I've tried running inspect both normally and as an administrator as suggested in https://stackoverflow.com/a/7833728/44737, and it behaves the same either way.

What, if anything, am I doing wrong? Am I just too impatient and do I need to wait a really long time instead of assuming inspect is hung? And why does inspect's behavior regarding AutomationId vary?

Solution

  • There are more than one version of Inspect.exe. The latest to my knowledge is the one dated from 2012 that says version 7.2.0.0 in the help/about dialog box.

    The old one doesn't have a tree view on the left with all detected automation elements displayed in a tree, so it's easy to check you're using the right one.

    The latest one works quite correctly, however, IMHO, the best tool so far to work with UI Automation is Visual UI Automation Verify. It's a .NET program, and he source is available here: UI Automation Verify (UIA Verify) Test Automation Framework.

    Note that although it's a .NET program, it doesn't use the standard .NET automation dlls (more on that here: What's the difference of UISpy.exe and Inspect.exe? (From Microsoft Windows SDK)).

    About the AutomationId property, to clarify my initial comment to the question, I meant its usefulness depends on the program that you're trying to automate.

    If you own it as a developer, it's clearly interesting. For example, if you're working with WPF, you can use the x:Uid property, it's clearly meant for UI automation. In the Winforms space, it's also quite useful because UI Automation will use the control's AccessibleName by default and revert to the Name as a fallback, for the AutomationId value.

    But there are many apps that don't rely on .NET (browsers, native apps, etc.) Usually, for these apps, it's easier to use other properties.