I have 2 occuerrences of the 'Another handler already registered for messages from process XXXX' error.
Older occurrence was when a given Webadapter was started to launch an external WebApp and the target process (IEXPLORE.EXE) is attached to WindowsProcess object. This error used to halt the automation completely.
The recent one is when link between WaitForCreate(WFC) of a webpage and pause that is on the True port of WFC is executed. This time it allows the automation to run without any problem. (Refer the attached error_DoesntStopAutomation.txt for error log).
I know that Runtime allows the show to run with few exceptions that it can ignore exceptions, and halts the execution in case of an unignorable error. My question is how is that decision made, especially when its the same kind of error?
(Will upload error log snippets for both errors shortly)
***Edited by Moderator Marissa to update SR Details***
Without examining your solution and your logs, I could not say for certain, however the exception in the prior post is caused by having two adapters effectively hooking the same instance of the application. Don't do that and you should avoid the error. The errors that get hidden by that setting in the RuntimeConfig (SuppressAdapterExceptions) are ones caused by the adapter and not by the automation. If you have an exception happening because of an automation step, then it is not an adapter exception.
I do believe this is actually a product defect. I would suggest that you open an SR to have support collect logs. It seems there may be a bug whenever an adapter is restarted and the PID is re-used. If you do open an SR, please include the number here for tracking purposes.
I understand. I missed out on mentioning this that I have observed the PID being re-used, especially for the iexplore.exe process that is created when the adapter is restarted immediately after stopping (it might seem like a weird thing to do, but thats how its being done for the current project).
I would open an SR and get this behavior checked. I would share the logs in here, too.
Appreciate your kind support and time to answer this.
A correction and some more information regarding this problem.
2. A slight different behavior is observed for the case where the robot is halted. The WebAdapter tries to stop the IEXPLORE.EXE process attached to it and logs that 'Process IEXPLORE.EXE with id 7804 has been destroyed.' followed by the 3 lines:
'Stopped Process - name: IEXPLORE.EXE' >> 'Adapter SearchF2 failed to stop process 7804' >> 'Adapter stopped'
Then further below the adapter is started again and while attaching the IEXPLORE.EXE with a new PID (6992) we get the error.
I will upload the detailed logs for these as soon as I get them approved by Client today.
1. SR-C52319 was resolved due to stagnation. The effort required by the customer was not proportional to their desire to resolve the issue since for them it was so rare.
2. As I understand the issue, it is not an automation issue and insytead a core product issue where it is unable to handle a process ID being re-used during a runtime session.
3. I do not know. I would contact support and they should be able to provide that information.
4. There is no way to workaround it. You can restart Runtime if you detect the issue, but there's nothing you can do to the current Runtime instance should it occur. I would recommend that you open your own SR to have the issue looked at for you specifically.
SR-C52490 was closed as the issue was being handled using SR-C52319.
There was a CR against SR-C52319 as well.
SR-C52319 was closed due to stagnation, along with it the CR for the engineering team as well.
So there is nothing with which we can be sure that the issue has been resolved and released.
So although we have SR-C52490 been closed as 'Resolved-Future release', the issue might still be there. There is a faint possibility of the issue having been resolved due to other fixes and modifications in the latest release of RAR/RAS, but we have to check it.
I think I will want to keep this thread open so that we have a logical closure.