Unstable Shared variable engine (tagsrv.exe)

[Kennethh]

Hello all.
I have some trouble with my monitoring system with the use of network shared variables. The Shared Variable Engine (SVE) keep crashing. No popup messages appears. I have to check taskmanager\services to see if it runs or not. I will notice that the SVE is not running in my applications, but the SVE seem to be just as unstable when none if my labview executables are running. In both cases the variable libraries are deployed to the SVE and in run state.
The crash may happend a couple of times a week or ceveral times a day. It varies. I have not succeeded in finding the direct cause for this unstable SVE.
In Windows Event Viewer\Windows logs\System i have noticed an error message that pop up around the same time as the SVE crash, every time, and is as follows:
Application popup: Microsoft Visual C++ Runtime Library : Runtime Error!
Program: C:\Progra...
R6025
- pure virtual function call
See attached files for more details from events and error reports.

Logging and alarming is working perfectly good and is doing just as expected most of the time. A restart of the SVE (nitaggerservice) usually fix the problem. But this results in a lot of "unacknowledged" alarms every time it crash. These cannot be ack'ed at a later time, and I am stuck with an extreme number of active alarms in my database.

My system is used for monitoring and logging at a slow rate (1Hz) and raises alarms if neccesary through the DSC module. The libraries holds around 300 variables in total. 3 libraries (1 which includes 9 sublibraries). Most of the variables are connected to FieldPoint, compactFieldPoint or DAQmx channels.
Since our hardware includes FieldPoint (and compactFieldPoint and compact DAQ) Ethernet devices we are unable to use any labview software after 2011. This limitation is set by the Fieldpoint driver.

The computer is a virtual machine running MS Windows Server 2012 R2 with the following NI SW:
- LabVIEW Run-Time 2011 SP1 f2
- LabVIEW DSC RTS 2011 SP1
- FieldPoint 6.0.10
- DAQmx 14.5.1

Have anyone else experienced a similar problem or? Any ideas for a solution would be greatly appreciated.

Best regards

Kenneth Henriksen

Norway

[SarahMC]

Hi Kenneth

So there is a couple of things you can try here:

In the following thread there a couple of suggestions

https://forums.ni.com/t5/LabVIEW/Shared-Variable-Engine-Crashing/td-p/1126160

1. Try to disable the NI Citadel service and restart the system

2. Go to Distributed System Manager and end all processes, and then try to restart LabVIEW

If the memory is increasing for tagsrv.exe causing it to crash then the following link from NI has some solutions in it-

http://digital.ni.com/public.nsf/allkb/F766A77CC235BD9D862576C000703A8E?OpenDocument

And finally, there is a possible link to this being caused when using a multi core PC, and in which case, the following steps may help-

1. Disable the Diagnostic Logger:
a. Right-click on the I/O Server Variable in the LabVIEW Project

b. Select Properties

c. Select the Diagnostic tab

d. Uncheck Enable Diagnostic

2.Disable Multicore operation within the PC BIOS (if supported).

I hope this helps!

Thanks,

Sarah

[Kennethh · Accepted solution]

Hello Sarah.
Thank you for the support.

By disabling the NI Citadel service, I guess you mean stopping it before rebooting the system. I have done so, and now have to leave the system running for a few days and see if there's any improvement. I found that the Citadel4 service also was running, even though I do not have any older databases in my system. I decided to "disable" this service upon startup since it isn't needed, then I rebooted the system once again. I do not yet see any problems from this decision. 

Before rebooting the system, I stopped and then removed all processes registered in Distributed Systems Manager. 

The memory for tagsrv.exe do not increase, neither do the cpu usage. The levels occupied are normally lower than 10% CPU and 100MB RAM. But I have noticed the memory for "SQL Server Windows NT - 64 Bit" (citadel) is increasing (I don't know if this is up to a point where the SVE is crashing). I just noticed this service is of 64 bit version. All LabView software is 32 bit. Would this maybe cause a problem. I have found SQL server components in both 32 and 64 bit program files folders, and the citadel instance is placed in the 64 bit version. I'm running "SQL Server 2008 R2".

The cache size for the Citadel page index referred to in the second link you provided is still the default value (512) which should be more than enough for my 300 or so variables. I will try to increase this limit if the SVE crash problem persists.

Disable Multicore operation within the PC BIOS (if supported):

- I do not use any I/O Server in my projects. The variables are all inside libraries (*.lvlib). Should I rather use IO servers to hold the variables?
- I will have a look at disabling multicore operation after I see the results from the actions already taken.

Thank you so much for the suggested steps towards a solution.

Best regards

Kenneth

[Kennethh]

Thank you for the suggested solutions to my SVE crash problem.
It seems like the multi-core processor operation was the cause for it all.

It is worth mentioning that my experience is that this problem occur mainly when there are network variables bound to daqmx global virtual channels in "max:my system". When the system was connected only to the older (compact) FieldPoint Ethernet modules it was running stable for extended periods of time.

Anyway, the system have been running stable up to now after reducing to only one CPU core, although the system seem a bit slower now.

Thanks for all the help. Hope it runs fine in the future.

Best regards

Kenneth.