Failed to get control

Sep 15, 2015 at 2:28 PM
Edited Sep 15, 2015 at 2:30 PM
I have a few commands that were working great, and then all of a sudden everything started failing and I can't figure out why. I've been working in a VM, so I eventually got to a point where I decided to just roll back to an earlier Snapshot and start over, but now I can't seem to get to a point where anything is working at all again.

For example, why isn't the following working anymore?:
Get-UiaEdit -AutomationId '1613' -Class 'Edit' | SetUiaControlText 'test';
Output is:
Get-UiaEdit : failed to get control in 2000 milliseconds by: title: '', automationId: '1613', className: 
'Edit', value: ''.
At line:1 char:1
• Get-UiaEdit -AutomationId '1613' -Class 'Edit' | Set-UiaControlText 'test';
• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo          : OperationTimeout: (:) [Get-UiaEdit], Exception
    • FullyQualifiedErrorId : ControlIsNull,UIAutomation.Commands.GetUiaEditCommand
and here is a screenshot proving that this should be working:


Full Size Image Link:

Likewise, the thread I made here is no longer working either when it was once working perfectly:

Anybody have any ideas what has gone wrong? Am I overlooking something simple?

Sep 15, 2015 at 2:55 PM
Hi xevilrobotx,
could it be that 2000 milliseconds used in the thread you mentioned in no longer enough? Could it be something that slows down your VM? Additional software on the VM, another VM consuming the host's CPU, etc.
Sep 15, 2015 at 2:58 PM
Edited Sep 15, 2015 at 2:59 PM
I should have mentioned that I also tried it on my Host machine with the same results and tried setting -Seconds 30, and then -Seconds 60 with no luck either.
Sep 15, 2015 at 3:28 PM
I tried the same app on my Windows 8.1 x64 and the following works:
Get-UiaWindow -Name *mic*drive*bus* | Get-UiaEdit
Setting value also works:
Get-UiaWindow -Name *mic*drive*bus* | Get-UiaEdit | Set-UiaControlText "aaa"
Could it be that you have gotten another window and now you are trying to get an Edit starting your search from another window?
Sep 15, 2015 at 3:40 PM
Edited Sep 15, 2015 at 3:50 PM
Could it be that you have gotten another window and now you are trying to get an Edit starting your search from another window?
I wasn't getting another window first, BUT I think you saying this has made me understand what I'm doing wrong!

I didn't realize that you needed to select a window at all to begin with, I thought it would just grab the UiaEdit with the automationId id and class if it was open and existed. So yeah, user error by not understanding completely how this is supposed to work :)

I was just trying to use something like:
Get-UiaEdit -AutomationId '1613' -Class 'Edit' | Set-UiaControlText "aaa"
when I needed to do something like:
Get-UiaWindow -Name *mic*drive*bus* | Get-UiaEdit | Set-UiaControlText "aaa"
In the other thread I linked to (, I must have selected the window at some point before I did that because I just started using this yesterday and had been trying a bunch of examples to learn.

Thank you so much!!
Sep 15, 2015 at 4:18 PM
Edited Sep 15, 2015 at 5:27 PM
Just as good practice:
  • be sure using the right root. This could be something you get using Get-UiaWindow, or a variable like $my_wnd_root = Get-UiaWindow, or event a menu or a pane that could also exist under the Desktop (Get-UiaWindow consider them as windows automatically)
  • use only right 'hops': if the spy offers you something like that: Get-UiaWindows -name -class -automationid | Get-UiaPane -Class -Name -AutomationId | Get-UiaEdit -Name -Class -AutomationId, the recommended way is to throw out unnecessary parts of the path and use the shortest minimum: Get-UiaWindow -Name | Get-UiaEdit
    In case one works in software development where ids and names are going to be changed on a weekly or daily basis, there would be less to change in scripts.
    The spy honestly offers the full path, it can't think, unfortunately, fortunately we can.
  • sometines MS UI Automation puzzles us with such a strange thing: a control could be given with hovering over it, but the search fails. Well, in this case we need to change search arguments.
  • sometimes your search takes too long or gets a control but fails with timeout thereafter. Probably there is in you app a control with the same id or name deeper in the hierarchy or in a neighboring pane. And search honestly tries to achieve all controls with the id or name you have chosen.
Upd: in the future versions the timeout exception will be more verbose:
Get-UiaButton : failed to get control in 5000 milliseconds by: title: 'Close', automationId: '', className: '', value:
''. Search was performed from @{IsContentElement=True;ControlType=ControlType.Window;Name=Windows PowerShell;IsRequired
Marked as answer by xevilrobotx on 9/15/2015 at 8:31 AM