Inconsistent "Failed to instrument WPF process" problems

Ask general questions here.
Darwin
Posts: 26
Joined: Tue Jul 25, 2017 9:00 pm

Inconsistent "Failed to instrument WPF process" problems

Post by Darwin » Fri Mar 23, 2018 6:30 pm

I keep running into this problem--our AUT is a desktop application; I'm running Ranorex 8.0.1 on Win10 x64; Ranorex and our app are both running as 32-bit instances; and in my test cases I'm typically launching the application in start-up and closing it in teardown.

I will see this warning and typically get 2-3 failures, in which Ranorex can not find the modal dialog our AUT presents on start-up, while running our test suite of 30+ test cases, and it is not always the same test cases generating it. The log will show the screenshots where the dialog is front and center, but Ranorex can not find it--I assume it's due to this WPF problem each time, although only the first failure displays the warning.

I've gone through several threads about this problem and tried uninstalling/re-installing Ranorex, our AUT, and the .Net Framework. UAC is at its lowest setting. I have the plugin setting at "WPF Preferred". While creating and debugging test cases, I've tried starting Ranorex Studio both as an admin and as a "normal" user for comparison, yet regardless I find quite often while trying to run any particular test case from within Ranorex Studio I will encounter this warning frequently and have to stop and restart the test case, hoping the next time the warning will not resurface.

The inconsistency is incredibly frustrating. Has anyone else encountered this? Any suggestions?

Darwin
Posts: 26
Joined: Tue Jul 25, 2017 9:00 pm

Re: Inconsistent "Failed to instrument WPF process" problems

Post by Darwin » Fri Mar 23, 2018 10:45 pm

After messing with this for a couple days and looking for some common attributes among the test cases that encounter this most regularly, I believe I've found the culprit. Apparently trying to access the AUT's UI from within user code *before* the UI is accessed by the inline recording steps is triggering this. I would leave it to the experts to confirm, but I expect there's a race condition for this WPF thread to reach a certain status, which the inline steps must wait for--but user code does not?

In any case, what I did was move up this "WaitFor" step from 8. to 6., moving my user code step down to 7. I've had several runs now without the "Failed to instrument..." warning and without failures.
StartupSteps.png
You do not have the required permissions to view the files attached to this post.

Darwin
Posts: 26
Joined: Tue Jul 25, 2017 9:00 pm

Re: Inconsistent "Failed to instrument WPF process" problems

Post by Darwin » Mon Mar 26, 2018 5:56 pm

My test suite ran multiple times over the weekend smoothly and perfectly. This appears to have fixed the issue.

I would appreciate confirmation from Ranorex support--if you can repro this situation by trying to access the UI from user code before accessing the UI from a "normal" inline recording step. It has caused me several weeks of glitches and inconsistent results and made me question whether we made the right choice in purchasing Ranorex--we seldom had a successful run of the test suite without running into at least one failure where Ranorex could not recognize a control while the accompanying screenshot showed the control clear as day.

Now I've had a weekend of multiple runs without a single failure and am looking forward to making our test suite much more encompassing and robust if this continues.

My repro steps were basically:
1. Create basic WPF Windows app as AUT
2. Add a test case and recording
3. In recording add a user code module
4. In user code function, try accessing UI, e.g.:

Code: Select all

if(<control/dialog>.SelfInfo.Exists(new Duration(60000)))
{

  <control>.Focus();
  <control>.Click();
}
else
{
  Report.Log(ReportLevel.Info, "<control> not found.");
  throw new Exception("<control> not found.");
}
Result: Intermittent "FAILED TO INSTRUMENT WPF PROCESS" warnings and log entries "<control> not found."

The only step I took to correct this is, as described above, move a recording step that references the UI so it executes before the user code step.

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Inconsistent "Failed to instrument WPF process" problems

Post by Support Team » Wed Mar 28, 2018 10:02 am

Hi Darwin,

Thank you for sharing your experience and solution to the mentioned behavior. We can confirm that adding a hard-coded delay right after the start of the AUT or after Click()-actions, which would navigate to different sections within the AUT, can and did resolve strange issue for some of our customers.

Sincerely,
Robert