Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

QuickOPC with PowerShell - Register-ObjectEvent

More
16 Jan 2018 06:49 - 16 Jan 2018 06:50 #5870 by support
Hello, I investigated this quite a lot, but unfortunately I have no good result so far.

Here is what I have found: It appears that most memory is occupied by the event arguments objects that we send to PowerShell. But it is not us holding - it is some kind of queue inside PowerShell that is not being cleared. Attached are screenshots from memory analysis from one of the test runs that show that the "root" that is holding all the objects is a local variable in PowerShell:








But when I made small programs that mimic what we do, PowerShell did not show signs of the leak. I could not think of something special we do, except for a library that we use and that takes over some system calls. After turning it off (see kb.opclabs.com/How_to_disable_prerequisites_boxing, done in the configuration file powershell_ise.exe.config), it seemed that the memory leak indeed disappeared. But after roughly 30 minutes, the memory started growing again.

I suggest that you try the steps at kb.opclabs.com/How_to_disable_prerequisites_boxing as well, if for nothing then for a possibility that the boxing can also have something to do with the crashes (which I could not reproduce at all).

But, if the memory leak persists, I would recommend you to use the "event pull" mechanism instead (as you already suggested). The problem seem to be related to PowerShell event processing only, so this resolve it.
Attachments:
Last edit: 16 Jan 2018 06:50 by support.

Please Log in or Create an account to join the conversation.

More
08 Jan 2018 15:34 #5830 by Enrico
Hi, your system configuration could be interesting. There was the effect, that with the activated heap monitoring from the Visual Studio Debugging, the crash did occur very late at the memory overrun.

My configuration is the following:
* WIN7
* opclabs - 2017.2
* PowerShell V5.1.14409.1012
* CLRVersion 4.0.30319.42000

I also tried on a Win10 machine, same result.

Ciao

Please Log in or Create an account to join the conversation.

More
08 Jan 2018 13:20 #5824 by support
Thank you.

I can confirm the memory increase - I was able to reproduce it. I will investigate it further and let you know here when I have more information.

So far I could not reproduce any crash (leaving aside that if the memory is fully consumed, it would probably crash - but that's to be expected).

Best regards

Please Log in or Create an account to join the conversation.

More
04 Jan 2018 17:07 - 08 Jan 2018 09:07 #5807 by Enrico
Hi thanks for the hint. That was a very good idea, but unfortunately it doesn't change the situation.

Here is the code, I implemented:
$myEventHandler = Register-ObjectEvent -InputObject $client -EventName DataChangeNotification -Action { if ($EventArgs.Exception -eq $null) {Write-host $EventArgs.AttributeData} }
I also already tried to catch the exception with the error mechanism:
$myEventHandler = Register-ObjectEvent -InputObject $client -EventName DataChangeNotification -Action { try {Write-host $EventArgs.AttributeData} Catch{Write-host "failure"} }

It also didn't help.

And even this (no action at all) will lead to the same effect:
$myEventHandler = Register-ObjectEvent -InputObject $client -EventName DataChangeNotification -Action {}
Last edit: 08 Jan 2018 09:07 by support.

Please Log in or Create an account to join the conversation.

More
03 Jan 2018 17:54 #5803 by support
Thank you.

May I ask you to do one change to your event handler (and re-test and report the result to us). Please re-write according to the guidelines mentioned here: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...AttributeData%20property).html .

That is, only access the AttributeData property when Exception == null. When Exception != null, the logger should not attempt to access the AttributeData at all - instead, it should somehow log the error/message.

Accessing properties of AttributeData is of course impossible when AttributeData == null (when Exception != null), and would lead to a CLR error.

Best regards

Please Log in or Create an account to join the conversation.

More
03 Jan 2018 15:03 #5799 by Enrico
Hi,

I do it per script. But it also can be done line by line. Or the lines can be copied from the script into the shell (I do so fot troubleshooting). All the same result. I just wanted to say, a 'wait' or 'sleep' statement might not be needed in all cases as the powershell is in wait mode anyway if it has nothing to do waiting for the next command.

Ciao

Please Log in or Create an account to join the conversation.

More
03 Jan 2018 14:10 #5798 by support
Hello,
thank you for all the information.

The 0xE0434352 error denotes an unhandled CLR (= .NET) exception, but without further details.

I was not aware that you run the script one by line. I thought you are running a script from a file.

It looks like that I will have to set it up here and try it out.

Regards

Please Log in or Create an account to join the conversation.

More
03 Jan 2018 12:46 #5794 by Enrico
Hi again,

here are the results from the debugging with Visual Studio.

(1) The first picture shows the exception leading to the powershell crash. The full error code is this:
Ausnahmefehler bei 0x000007FEFD27A06D (KernelBase.dll) in PowerShellToolsProcessHost.exe: 0xE0434352 (Parameter: 0xFFFFFFFF80131501, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x000007FEE7430000)

(2) The second picture shows the windows heap. It starts increasing slowly and all of a sudden it gets crazzy. I have highligted the last heap snapshot. That indicates the service/process filling up the heap.

By the way, when I activate the heap monitoring, the script runs more stable. It fails when there is a memory overrun. Thus the heap monitroing does something that keeps everything in line.

(3) the third picture shows the windows heap when putting the powershell into the sleep mode. The same behaviour. By the may the memory allocation is in the range of 5 GB (and increasing :o)
Attachments:

Please Log in or Create an account to join the conversation.

More
03 Jan 2018 12:33 #5793 by Enrico
Hi,

(1) Wait statement not needed
in the meanwhile I checked with the start-sleep command. The failure behaviour doesn't change at all. The only difference is, that the function that is called in case of an event, is also no executed. Thus the powershell is doing nothing.

Technically that makes sense to me. The powershell is a command line tool. Line by line I can execute the commands. After the command

$client.SubscribeMultipleMonitoredItems($arrMonitoredItems)

the powershell is automatically in the wait mode, and waits for further commands. Thus no explixit 'wait' is needed. As long as the powershell is not closed, the events are registered with that powershell.exe. Would you agree?

(2) All events captured?
As the behaviour concerning the heap and the memory is very much similar, in both cases (powershell processing the event and powershell not processing the events), there is the suspicion that the events are not taken from the event heap.

I tought it would be a good idea to look deeper into this event heap. Is there an alternative way to access the events? Like pulling them actively and deleting the queue/heap?

Please Log in or Create an account to join the conversation.

More
03 Jan 2018 11:22 - 03 Jan 2018 11:22 #5792 by Enrico
Hi,

Happy New Year!

In the meanwhile, i went back to the Visual Studio debugging. With the option propossed by you 'attache with native' it is possible now to log the crash and to get more insight.

Before getting to these results, I will try with your last hint. Indeed, there is no last line. The script just finishes with no errors and nevertheless the exeptions are raised. Maybe the missing process is the reason for the undefined behaviour. I'll give it a trial, and get back to you. With the improved Visual Studio debugging it should be possible to quickly identify if the problem is gone ;o)
Last edit: 03 Jan 2018 11:22 by Enrico. Reason: typo

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.064 seconds