“This is the application template and cannot be run alone.” – “Possible path leak, unable to purge elements of base #0”

[Christ0phe]

Hello,

I am running into a strange situation: I have built an executable (lets say V3 of the application) that runs well on all my 100 stations except one where it leads to the following error when being launched:

“This is the application template and cannot be run alone.”

All the stations are configured the same way, same Windows 7, same Labview 2012 runtime engine. The odd thing is that all previous versions (V1, V2) of this same app are working well on this station, only the last compiled one (V3) does not. If I recompile the code (V4, V5), again, it works on all stations but this one. Previous versions (V1, V2). The differences between the versions are merely tiny re-wirings.

I have checked the Firewall exceptions, no problem there. I have logged in as other administrators and non-administrators users, still the same problem…

Any help greatly appreciated…

Thank you

Christophe

This is what I see in the error file:

####

#Date: 29. 1 2021 5:13:41

#OSName: Windows 7 Enterprise Service Pack 1

#OSVers: 6.1

#OSBuild: 7601

#AppName: DASIP_676

#Version: 12.0 32-bit

#AppKind: AppLib

#AppModDate: 01/28/2021 18:09 GMT

#LabVIEW Base Address: 0x30000000

Possible path leak, unable to purge elements of base #0

[pincpanter]

Hopefully this page can help you, although it does not seem very promising.

The very same cryptic message is reported in various posts of this forum, but most of them has no happy end. Except one poster that solved reinstalling the application.

[Christ0phe]

Hello Paolo,

Yes I was aware of the KB that you mention. But like I said the exe works well on all other PCs and secondly I have rebuilt the same exe and it leads to the same error message.

I fear I will have to rebuild the whole PC but it bodes me not to understand the root cause of the issue.

I do not know in which error report or log file I should find more accurate information allowing NI guys to figure out what the true problem is…

[rolfk]

What are the OS language settings of the different stations?

[Christ0phe]

All stations exactly the same: Windows 7 Enterprise.

All PC configured exactly the same way, same Firewall rules also. 

[rolfk]

Firewall rules should not come into play at this stage. The way LabVIEW executables are build is that there is a precompiled executable stub and the application builder then adds the archive containing the compiled VI resources to the executable stub. The stub only loads the LabVIEW runtime, initializes it and then locates the VI library archive and loads that and hands control over to the top level VI from that archive. For some reason the stub seems to be unable to locate the VI archive tacked on to itself. This has nothing to do with networking but with locating resources inside its own file.

There are several levels where this could go wrong, one of them is locating the resource in the executable file itself. And resources can be stored with a so called language ID, which has nothing to do with if it is Windows Enterprise or Home or whatever but with the actual regional setting your Windows system is configured for (for oldtimers this is the codepage your system uses).

So are all the Windows systems configured for English (US) or are there differences? The only other potential problem I can see is also language related and is mentioned in the knowledge base article. When you build the application on a system which uses multibyte encoding (some Asian languages use that), the names and paths of the VIs in the archive can be encoded as multibyte characters if you use non ASCII-7-byte characters in the names and when you then load the executable on a system with different language encoding, the paths are messed up and the LabVIEW runtime can't locate the VIs in the archive.

[Christ0phe]

Application is built on a platform with Windows 7 US version. It runs on Windows 7 stations configured mostly in US but also in other languages and it works well everywhere except here on this specific PC. On this specific station regional options were set in Slovakian (like 10 other stations on which the same app runs without a problem). I have reverted the language to US, locale as well, restarted the PC and the problem is still there… and previous releases of my app still work well on this doomed station ! What a mystery !