Placement of KillallProcesses.xaml in State Machine

Hello,

I’m trying to understand the placement of the [KillallProcesses.xaml] in the Init State Machine. I’m using the REFramework Template that’s part of 2019.7.0 CE . Here’s a screenshot of the area where I’m a bit confused:

Issues and Questions:

The UIDemo Project works completes step 1. without any incident and loads all the config and asset settings .
But then at step 2, [KillallProcesses.xaml] is invoked sequentially and unconditionally.
Here, my code terminates with an exception because the process UIDemo has not actually happened yet. Therefore, there is nothing to kill!

So, comes the question - Why does the state machine have to go to [KillallProcesses.xaml] at this point when there are no errors?

The Kill Process activity expects an argument which I believe is:

System.Diagnostics.Process.GetProcessesByName(“UIDemo”)(0)

And even if the sequence did invoke [KillallProcesses.xaml], how should it react when the process it has to kill hasn’t taken place yet?

thanks!

Also, the default framework implementation of to KillallProcesses.xaml has a simple log output and therefore it would work without errors.

But when this step is actually implemented with a Kill Process step, do we have to change the process name to match the state machine? And what would be the name in this case?

The download for the PDF for Level-3 training states that these steps are straight forward.

Based on what I’ve encountered, I’m either following the wrong documentation, or the KillAllProcesses step is not straight forward.

Please confirm.

thanks again!

Hi @AndyMenon!

Can you please share a screenshot of your KillallProcess.xaml?

Here it is. I added the Try Catch a few minutes after my initial post.

Hello again @nerlichman

Hit Reply too quick. The Catch block not visible in the screen grab above prints a simple log message stating “No process to kill” and exits.

Could you try using the “ProcessName” argument instead of “Process”?

You should set “UiDemo” or “UIDemo”, and empty the “Process” argument.

Please see this explanation for clarification: How to use Kill Process

Yes that was my next thought. But, why ?
Why would the control have to go there where there are no errors?

Let’s suppose I give it “UIDemo”. What if it worked? Then the process would be killed even after the Init state machine has worked correctly?

Sorry, if my reasoning is off here. But shouldn’t the state machine evaluate the reasons to call the Kill .
Couple of cases would be if the Config collection has zero keys or if the Orchestrator queue name isn’t loaded.

The InitAllSetting doesn’t open applications, it only sets the Config dictionary.

The kill all processes is called so the process will start with a clean environment, after that at the end of the init state, the InitAllAplications is called, that’s where your apps must be opened.

I’m replying from my phone, as soon as I get to my PC I’ll explain further if you need it.

Understood.
When the application starts up the first time, there is already a clean environment and no UIDemo process running. Example: A system reboot.

What should KillProcess do then?

Ok,
My robot is working as intended. I started the Main REF machine once in a clean environment and once with the UIDemo already open.

I see that the Process Name argument doesn’t cause the Kill Process to fail in a clean environment. But it effectively kills the UIDemo app if it’s already up and running.

Now this makes sense.

Following which, I’ve updated the Annotation on the Kill Process XAML to avoid future confusion. Sharing the same here:

thanks for your help.

1 Like

An update: I’ve been working on the Client Security Hash Project. In this case, the process to kill are browser based. Therefore, what happens if the admin has left a browser window open on the robot machine?

Example: In my day to day work, we leave a browser page that monitors our integration processes open all the time. Won’t the robot kill this window too?

I made minor mods to my KillAllProcesses.xaml and it accepts a Process_Type argument from the config file. If the type value is Browser, the workflow tries to attach to Browser windows by specific titles and then close them out. In this case, these windows are like ACME* and SHA* . If these windows aren’t found, the Catch block will bury the exception with a silent Log message. Here’s how it looks:

Utility Rig to find process names to kill:
Usage is added to annotation and reproduced below. I’ve made this workflow independent, but part of the framework under the \Common folder.

The output of this rig can be used to configure KillAllProcesses framework workflow.

I hope this helps.

Identify_Processes_By_Name.xaml (8.9 KB)

Test Sequence to Identify the Process Name that needs to be killed by the RPA Process

Usage:

  1. Start an instance of your process that needs to be identified for termination - Example: A few windows of Google Chrome or Microsoft Edge

  2. Enable Seq 1 and run this Workflow
    Seq 1 will output a list of Process Window Titles (where available) and the Process Name

  3. Identify the process to be terminated - Example: “chrome”

  4. Disable Seq 1 and Enable Seq 2.

  5. In the Kill Process Activity of Seq 2, configure the Process Name attribute with the name of the process from Seq 1

  6. Run this workflow with Seq 2 enabled - in this case the expected result is for all Chrome windows to be terminated.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.