Very occasional Ranorex freeze when trying to find a window

[Ciege]

Very occasionally, but more often now than it has been in the past, I am running into a scenario where I use a FindSingle command to search for a window (that may or may not exist) and Ranorex will freeze. In other words the Find starts, but never times out when the window is not found.

Here is the command I am using (it is wrapped by a try/catch to catch any form not found error):

Code: Select all

HDForm = Host.Local.FindSingle("/form[@title='" + WindowName + "' or @controlname='" + WindowName + "']", Timeout * 1000);

When it happens it is usually during a test that I have that runs for several hours (4+). And it usually happens several hours into the test.

This occurs on XP 32bit and W7 32 bit using Ranorex version 3.0.2. When it happens I get no error or exception in the logs, the CPU and memory consumption are all "normal" (i.e. nothing is spiked or hung). Nothing seems amiss, just the find starts and then goes out into the weeds...

Any suggestions you have that I can try out?

Thanks...

[sdaly]

Hmmm we had a similar situation which was due to a deadlock...that issue was fixed though....

Does the execution hang? If so then what happens when you close the target app, does the execution continue?

Out of curiosity, why do you use FindSingle and wrap within a try catch? Have you tried using TryFindSingle instead? I see you multiple your timeout by 1000, I assume you pass the duration in seconds?

[Ciege]

If so then what happens when you close the target app, does the execution continue?

Not sure, will try that next time I see the issue.

Out of curiosity, why do you use FindSingle and wrap within a try catch?

I wrote this window search method very early on in my Ranorex usage / learning phase. So there may be better ways to do it, but this has always worked and I have had no need to change it.

I assume you pass the duration in seconds?

Indeed, my method takes in a timeout parameter that I request in seconds. I do a little check in the method to make sure it looks like the user sent in something reasonable that looks like seconds and then multiply that by 1000. If I determine the user sends in milliseconds instead of seconds I'll fix that before calling the FindSingle.

[Ciege]

If so then what happens when you close the target app, does the execution continue?

Ran into this again while having tests scheduled to run over the long weekend here... Closed the main AUT and the Ranorex code was still out in the weeds doing nothing...

[Support Team]

Do you have a single process running all the time or several processes running the test? I.e. does that issue happen at the very beginning of the test/process lifetime or just anytime?
What kind of technology do you automate at the time the freeze occurs? Is there a DOM (Internet Explorer) open at the time or integrated in your application?

Usually, all Find operations are aborted when the time out is reached. We use different techniques to ensure code in plugins cannot block the Find calls forever. However, these techniques may not work in some situations, e.g. when native code is executed or when communication uses COM as in the web and MSAA plugins. That's why I'm asking about the technologies...

Regards,
Alex
Ranorex Team

[Ciege]

Do you have a single process running all the time or several processes running the test? I.e. does that issue happen at the very beginning of the test/process lifetime or just anytime?

Two processes - the main test process and a workerObject thread that watches for unexpected exceptions from our AUT. Same two thread process is used within all of my scripts. Have been using this method for 2+ years...
The failure does not occur at the very begging of testing. It usually occurs several hours into the testing. This latest failure was just over 4 hours into a specific test. The find method is used hundreds of times throughout this script and the failure never occurs in the exact same place/time within the script.

What kind of technology do you automate at the time the freeze occurs? Is there a DOM (Internet Explorer) open at the time or integrated in your application?

This is our main AUT (.NET thick client) no DOM.

[Support Team]

Two processes - the main test process and a workerObject thread that watches for unexpected exceptions from our AUT

You mean threads, not processes, right? What I wanted to know is whether you only start one process/executable or several ones during your test run. I thought it could be an initialization problem with the Ranorex plugins if that freeze happens right after starting a test executable.

This is our main AUT (.NET thick client) no DOM... Closed the main AUT and the Ranorex code was still out in the weeds doing nothing...

That is really weird. If it hangs due to some communication with the AUT that cannot be aborted, then closing the AUT should unfreeze the find operation.

The next time that freeze happens, could you attach a debugger to the test process and print out the stack trace of the main thread? If you are using Ranorex Studio as debugger, make sure you have "Show external methods" enabled using the context menu of the stack trace window. We need to know exactly at which method the execution is stuck.
Then please let execution continue for a few seconds and repeat the stack trace print out, so we can check whether that is an infinite loop.

Another thing you could do when that freeze happens is opening Ranorex Spy and trying to search for the RanoreXPath the test process is performing the FindSingle on. Maybe Ranorex Spy freezes, too?

Regards,
Alex
Ranorex Team

[Ciege]

You mean threads, not processes, right? What I wanted to know is whether you only start one process/executable or several ones during your test run. I thought it could be an initialization problem with the Ranorex plugins if that freeze happens right after starting a test executable.

Yes, you are right, sorry... Two threads, one test process...

I will try and get a debugger session working on one of the machines to see what is happening. ay not be able to get to it today since it usually takes hours to occur and I have some other things high on my plate right now....

[befair]

Was there a resolution for this? I am experiencing the described behavior on almost half of the automation runs that I attempt today, and this is not the first time. I have seen it on Windows 7 as well as XP. Closing the AUT changes nothing. Where and whether the issue occurs is entirely random. I'm not following what you want done for the debugging Seems like the Callstack window (is that what you meant?) will only be helpful when a breakpoint is hit. Since I have no way to predict where the issue will occur, that doesn't seem workable. Please let me know what I can do to help troubleshoot this issue.

Thank you,
B

[Support Team]

Hi,

We are sorry but we do not know how Ciege handled this problem.
Please answer the following questions:

Do you have a single process running all the time or several processes running the test? I.e. does that issue happen at the very beginning of the test/process lifetime or just anytime?
What kind of technology do you automate at the time the freeze occurs? Is there a DOM (Internet Explorer) open at the time or integrated in your application?

Another thing you could do when that freeze happens is opening Ranorex Spy and trying to search for the RanoreXPath the test process is performing the FindSingle on. Maybe Ranorex Spy freezes, too?

Where and whether the issue occurs is entirely random.

But it is always a search method which triggers Ranorex to freeze?
If you would know where it freezes you could hover, in debug mode, over the method and analyze the values of there parameters. Maybe there are some wrong values?

Callstack window (is that what you meant?)

Some kind of yes, the callstack shows you the stack data structure that stores information about the active subroutines of a computer program, -> stack trace: A stack trace (also called stack backtrace or stack traceback) is a report of the active stack frames at a certain point in time during the execution of a program, it represents the frames on the call stack at the time the current exception was thrown.
To get the specific "Callstack" at the specific time, just attach the running process (exe) to the debugger, and when it freezes, "pause" the execution and send us the Callstack. Please, make sure that the "Show External Methods" is enabled by right clicking in the Callstack pad.

Which Ranorex version are you using, the actual 3.2?

Regards,
Markus
Ranorex Support Team

[Ciege]

We are sorry but we do not know how Ciege handled this problem.

Sorry all, I do try to followup all my posts. This one just slipped through...

I do see the issue very occasionally still and I have been unable to track it down or find a reliable way to reproduce. All my previous comments in this thread are still true. I have tried the suggestions in this thread as well as a few of my own, but have not come to any conclusions.

It is so random and so infrequent when it happens that it has been a very low priority for me to continue trying to figure it out.

[befair]

I have been watching for this issue, and here is the information I have now:
1. I am running a single process
2. It isn't just searches. Most recently it has been stalling before actually doing any of the automation steps. When I logged into the machine, I saw IE has experienced an error window. So it would seem that Ranorex, IE, and the AUT don't get along too well. I've never seen the error when manually running the application. Once this error state is hit, nothing else will ever happen. Last incident was two days ago, and the test is still just waiting.
3. I don't know what you mean by "trying to search for the RanoreXPath the test process is performing the FindSingle on." How can I search for paths in the spy? I did search for, and find with no problem, the control that was being searched for in one of the freezes.
4. Debugging is a problem because most of the time we are running automated tests on a remote server, but when my workload allows I'll put some time toward trying to get a stack trace.
5. I'm using 3.1.3 I plan to try 3.2.

[Support Team]

Hi,

I saw IE has experienced an error window

Can you send us a screenshot of that error window, some information about your test environment and please also tell us which technologies are used within your application?

Regards,
Markus
Ranorex Support Team

[befair]

I have attached a screenswhot of the latest error. This is not the same as the error I saw last time which was an IE error. The test environment is Windows XP pro version 2002 service pack 3 with IE 8 version 8.0.6001.18702IS 128 bit cipher. The application under test is a flex based UI.

[Support Team]

I have attached a screen shot of the latest error.

I'm sorry but there is no screen shot attached.

Regards,
Tobias
Support Team