I want to test on the newer PC but the issue seems to be an effect of how the NI Variable Engine responds to some registry settings. There is a page on the digital.ni.com/public tree titled “Why does tagsrv.exe Memory Usage Grow Until it Crashes?” I have implemented option 1 on the test system and it cut the startup time roughly in half. I have set the setting value to 8,000,000. The variable engine architecture seems to have changed drastically and this seems to be what is stalling the application from loading as quickly as it should. Once the panel loads on the screen there is another half-minute delay waiting for shared variables to percolate through and start to display live data rather than default (usually zeroed) data. The description says that if this is causing the error and the variable engine is swamped there should be error -180121600 or error -180121601 describing a message queue overflow. I get no error messages at all from variable read widget at all and the error output is wired as expected. During the build I made sure that debugging is off and memory usage seems to be reasonable for a newer LabVIEW version – it never decreases but usually increases somewhat modestly once the application has debugging off and the correct settings in the VI properties panel for application efficiency.
The machine in question is running Windows XP 32 bit, has a Pentium 4 CPU and 4 GB of RAM (the main board is maxed out). Trying the executable on a PC with a Core 2 dual core CPU and 2 GB of RAM shows similar results though I have not tested the registry change on that machine.
