System Outofmemory exception- reporting across multiple machines

[Chan_Thomas]

Hey everyone, 
I've scouted the forum for a similar issue, and have read many posts that have helped me understand why the System Error OutofMemory happens. 

I now need your help in identifying which machine this is happening on. 
We have 9 machines that all jump into various processes as and when, but one process, in particular, is throwing a lot of these exceptions. 

This exception doesn't appear in the queue report but shows in the emails we are sent, however, those emails don't specify which machine the issue is happening on. 

Short of asking someone to watch all 9 machines to check when this process is running to spot which machine it's on, I'm unsure how to report it. We thought about adding the Machine details to the exception emails we get, however, I don't think we control the system out-of-memory emails like that. 

Any help is appreciated, I am also very new to RPA so detailed explanations are useful, thank you! 

We're on V6.10.1 🙂 

[John__Carter · Accepted solution]

You can temporarily override the logging set in the process at machine level, and you can also have the logs include memory details. Do this on all machines for a while and you should find the culprit. Alternatively, right click on an exception queue item and click View Log, that should lead you to the machine name.

[Daniel_Sanhueza · Accepted solution]

I just want to add that you can use the Machine Name on the mails that the process is sending when encounters the error, that could say to you wich machine is having those memory issues.

Unfortunately, you can't know when a memory error will happen and you have to implement all best practices that I'm sure you are already looked for (if not check here). Even implementing all those strategies to manage memory at a process level, memory erros could potentially happen. 

I've faced the same situation that you are right know, process failing with memory errors but dont know how or when happened. Having said that, what you can do is prevent - in a proactive approach- that memory errors could even reach the threshold of failure. 

To do this is very simple, but you have to know a couple of things;

• v6.10 is a 32 bit architecture and the addresable memory is no more than 2GB ()
• The process Automate.exe could hang when the 1.5GB-1.8GB memory is reached.

Back in the "Solution", you can create a page named 'Validate Memory', inside put an action with the "Utility Environment:Read Memory Stats", if you leave the input in blank it will bring the automate process and that's the one we need. 

The output collection will be like this;

The column we need is Virtual Memory, so the next thing you need to know is the amount of memory that could cause the memory error. The way that I test this were reading large collection and checking the memory without cleaning the collections or calling the garbage collector. That will consume memory very fast and you will notice that a memory error is reached or the studio is very slow. If you reached the memory threshold and you're lucky that BP didnt respond (And eventually hangs), read the memory status and save the Virtual Memory, if the BP is slow read the memory status and that's the amount is prone to error. 

In my processes the threshold that I set were 1.4GB (Virtual memory bring these numbers in bits) so I created a Session Variable with that amount of bits and every time that you completed a case the flow calls "Validate Memory" and Send a True or False to the Main Page if the threshold is reached. Then you can alert, restart or do whatever you want to do in the next logic to prevent those issues. Personally, I've  restarted the machines and then start the process again (by scheduler) and continue the work where they left it.

Hope it helps to bring you lights on it.

Regards