openHistorian service is keep stopping

GPA Products openHistorian
1

Hi Ritchie,

We are running openHistorian 2.6 in one Azure VM and this PDC is connected with 50 PMUs directly and collecting data and frequently openHistorian is keep stopping and logged below error. Can you please help us on this issue. Is this kind of issue already fixed in latest version?

[11/11/2021 11:17:56 AM] Date and Time:         11/11/2021 11:17:56 AM
Machine Name:          
Machine IP:            
Machine OS:            Microsoft Windows NT 6.2.9200.0

Application Domain:    openHistorian.exe
Assembly Codebase:     C:/Program Files/openHistorian/openHistorian.exe
Assembly Full Name:    openHistorian, Version=2.6.30.2, Culture=neutral, PublicKeyToken=null
Assembly Version:      2.6.30.2
Assembly Build Date:   9/16/2019 1:14:56 PM
.Net Runtime Version:  4.0.30319.42000

Exception Source:      GSF.ServiceProcess
Exception Type:        System.InvalidOperationException
Exception Message:     Request is not supported
Exception Target Site: RemotingServer_ReceiveClientDataComplete

---- Stack Trace ----
   GSF.ServiceProcess.ServiceHelper.RemotingServer_ReceiveClientDataComplete(sender As Object, e As EventArgs`3)
       openHistorian.exe: N 02048

[11/11/2021 11:18:09 AM] Date and Time:         11/11/2021 11:18:09 AM
Machine Name:       
Machine IP:            
Machine OS:            Microsoft Windows NT 6.2.9200.0

Application Domain:    openHistorian.exe
Assembly Codebase:     C:/Program Files/openHistorian/openHistorian.exe
Assembly Full Name:    openHistorian, Version=2.6.30.2, Culture=neutral, PublicKeyToken=null
Assembly Version:      2.6.30.2
Assembly Build Date:   9/16/2019 1:14:56 PM
.Net Runtime Version:  4.0.30319.42000

Exception Source:      GSF.PhasorProtocols
Exception Type:        System.IndexOutOfRangeException
Exception Message:     Index was outside the bounds of the array.
Exception Target Site: ParseCommonHeader

---- Stack Trace ----
   GSF.PhasorProtocols.IEC61850_90_5.FrameParser.ParseCommonHeader(buffer As Byte[], offset As Int32, length As Int32)
       openHistorian.exe: N 00808
   GSF.Parsing.FrameImageParserBase`2.ParseFrame(buffer As Byte[], offset As Int32, length As Int32)
       openHistorian.exe: N 00055
   GSF.Parsing.BinaryImageParserBase.ParseBuffer(buffer As Byte[], offset As Int32, count As Int32)
       openHistorian.exe: N 00453

[11/11/2021 11:18:10 AM] Date and Time:         11/11/2021 11:18:10 AM
Machine Name:      
Machine IP:            
Machine OS:            Microsoft Windows NT 6.2.9200.0

Application Domain:    openHistorian.exe
Assembly Codebase:     C:/Program Files/openHistorian/openHistorian.exe
Assembly Full Name:    openHistorian, Version=2.6.30.2, Culture=neutral, PublicKeyToken=null
Assembly Version:      2.6.30.2
Assembly Build Date:   9/16/2019 1:14:56 PM
.Net Runtime Version:  4.0.30319.42000

Exception Source:      GSF.TimeSeries
Exception Type:        System.NullReferenceException
Exception Message:     Object reference not set to an instance of an object.
Exception Target Site: QueueMeasurementsForProcessing

---- Stack Trace ----
   GSF.TimeSeries.Transport.UnsynchronizedClientSubscription.QueueMeasurementsForProcessing(measurements As IEnumerable`1)
       openHistorian.exe: N 00307
   GSF.Collections.<>c__DisplayClass10_0.<.ctor>b__0()
       openHistorian.exe: N 00091
   GSF.Collections.DoubleBufferedQueueManager`1.CallItemHandler()
       openHistorian.exe: N 00021
   GSF.Threading.SynchronizedOperationBase.ExecuteAction()
       openHistorian.exe: N 00035
2

Hi Logu,

The only kind of exception that would cause service to stop would be an “unhandled” exception. Most code paths in openHistorianan are handled, e.g., in a try/catch. Your log entries above are are handled - so while these could cause connection or processing issues, they would not cause program to terminate. I suggest looking in the “Logs” folder using the LogFileViewer.exe tool and looking for unhandled exception or normal termination events in the log close to time when service stopped. If it was a hard crash, then the Windows Event Log would have captured the exception.

Also, yes, there have been may updates to stability since version 2.6.

Thanks,
Ritchie