Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
There have been multiple instances of Coded UI Test customers reporting failure in the performing action on a control within a popup window such as a dialog box or a context menu. The typical symptom will be an error thrown something like –
QTAgent32.exe, AL: Playback Error: Microsoft.VisualStudio.TestTools.UITest.Extension.FailedToPerformActionOnBlockedControlException:Window '' is blocking the control XYZ. Please move the window '' or make the control XYZ visible and retry the action. Additional Details:
ControlType: 'MenuItem' ---> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0xF004F003
First of all, note that this is not a search failure, but an action failure. If you observe this error even if the target control is well truly visible on the screen, the first troubleshooting action you need to take is to check if the search has actually hit the correct target element. You can make use of the DrawHighlight method in your test code to validate this. Often debugging this leads to the root cause of an earlier instance of the same window not being disposed off properly. This results in a stale accessible object persisting under the desktop and the search hits this stale object. Since this UI object is in reality not visible and obscured behind other UI objects, the playback fails with the blocked control exception error.
If you have access to the application code, I would suggest first to verify and fix this in the application. If this is not possible at given point of time, you could apply certain workarounds in the Coded UI Test to resolve this issue.
1. Make use the VisibleOnly search configuration for the target control (and its ancestors). If the search hierarchy looks something like TopLevelWindow(TLW) -> A -> B, append the configuration to each of all of these controls. The assumption is that the stale control’s accessible object will typically have its visibility property set to false.
2. Approach  may not hold good in all scenarios (at least I have come across certain scenarios where it does not work). The search may be picking up the cached control. In that case, you may also try out the AlwaysSearch configuration along with the VisibleOnly configuration. I always suggest the Coded UI Test users to use AlwaysSearch with caution since it impacts the performance. So use your judgment to apply this only for specific scenarios.
3. The stale control’s window would typically be as an previous sibling peer of the actual target control’s new window. So we have two windows with identical properties and identical hierarchy underneath it. To force the search to hit the second instance of the window, you can make use of the OrderOfInvocation property for the top level window. This property is essentially used to disambiguate multiple top level windows with identical properties (something similar to the “Instance” property you use for the controls within). In a simple case, if you could try setting something like – YourTopLevelWindow.SearchProperties.Add(WinWindow.PropertyNames.OrderOfInvocation, “2”) to ignore the first invisible window.
One final note on the visual verification using DrawHighlight() -
The stale window’s location could simply overlap the actual new window’s location. So the DrawHighlight() might just give a false visual impression that the search has hit the correct control! So you need to do some trial and error with the workarounds. To validate this, one helpful way is to write your own validation Coded UI Test script that gets additional information about the state of the desktop session. For example, if you suspect that there are multiple windows with identical properties, you can do a
WinWindow matchingWindows = new WinWindow();
UITestControlCollection windowsFound = matchingWindows.FindMatchingControls();
// And verify all the windows returned in the collection.
The approaches I’m described above can be extrapolated to all types of controls (not just top level windows). You can use this to debug scenarios for stale controls within a windowless application.
I have the same issue, but the error is due to a windows update. I suspect that KB2817393 is the culprit. After uninstalling this update,, the issue no longer was present.
This article fixed the exact problem: www.bitterminion.com/.../coded-ui-failedtoperformactiononblockedcontrolexception
We have a number of manually coded test scenarios, which have been built to run one after each other. When a new version of our bespoke software is released to QA for testing, the coded UI fails with these types of errors. I need to code something in 'MyTestCleanup' for each of the Coded UI test scenarios to clear down/kill/exit/clean up these errors so that the next test is unaffected. Often, it gets so bad that the next test times out. Does anyone have any ideas? P.S. Although I have been developing for many years I am new to C#
Looks like your application is left in an inconsistent state at the end of your test causing issues in subsequent tests. Instead of using test clean-up, you can try fixing the test or application to ensure a consistent state of the app at the end of the test. If you could provide details of your test, app and error messages, we would look to provide suggestions.
What would be really good is if the error message was actually meaningful. Giving the control that is supposedly blocking.
Also what exactly does "note that this is not a search failure, but an action failure" mean? I usually solve this by using "Playback.AlwaysSearchControls = true", which means it is a search failure.
This is a stale UI issue that results in Search finding the wrong (stale) control. The AlwaysSearchControls property when set to true will not use a cached queryId to search the control but would in fact reconstruct it, thus allowing the action to pass. Note that there is a perf hit with AlwaysSearchControls = true
I tried with all the search configurations suggested..but none worked for me..
The solution suggested by Forrest worked in my case: