Multiple executable instances running without AllowMultipleInstances set in INI file

[TurboPhil]

To my knowledge, the LabVIEW runtime engine prevents running multiple instances of a given executable unless you explicitly set the "AllowMultipleInstances" flag to TRUE in the corresponding INI file. But we just encountered a system in production where a user accidentally fired up a second instance, even though that INI file was not set. I confirmed that both instances of the process were running from the same absolute path (making sure it wasn't something sneaky, like a copied *.exe file).

I even tried explicitly setting "AllowMultipleInstances=False" in the INI and then running the exe again, and it still launched a new one.

Are there any other settings that could be impacting this functionality? For various reasons, we do not want to allow this to happen in production, if we can help it.

[tyk007]

What LabVIEW version?

I just tried out one of my LabVIEW 2020 executables and it works as it should - without the flag set, you can only have one instance open (attempting another moves focus to the original). If I add the flag to the ini file with "False" the behaviour is the same. if I set that flag to "True" then I get multiple instances.

[TurboPhil]

---

@tyk007 wrote:

What LabVIEW version?

I just tried out one of my LabVIEW 2020 executables and it works as it should - without the flag set, you can only have one instance open (attempting another moves focus to the original). If I add the flag to the ini file with "False" the behaviour is the same. if I set that flag to "True" then I get multiple instances.

---

This is using LabVIEW 2019 (for both the build environment and runtime engine).

Yeah, the behavior you describe has been my experience up until we encountered this particular situation with this one executable. That's why I'm asking if there might be some other contributing factor that I'm not aware of.

[playerm1]

Things to check/consider:

-Check if the top-level main VI is set as a clone in VI Properties >> Category: Execution

-Are there multiple LabVIEW runtimes installed on the production machine?

-Are there 32-bit and 64-bit versions of the LabVIEW runtime engine installed?  You may be able to see from Windows process list if one is running under 32-bit instead of 64-bit

-Are the multiple instances running under the same Windows user name?

[DavidBoyd]

Only time I encountered a similar situation on our factory floor, it was due to a second user logging on to the same machine and launching the same application under their desktop session, which isn't prevented by the token (second executable image is loaded in a totally separate security ID under Windows).

No idea if that's what's going on here, but it can be harder to detect than you might think. If the Windows task manager isn't launched with admin rights, I don't think it shows you processes running under other user's contexts.

Dave

[rolfk]

The method where LabVIEW checks if another instance is already running is using good ol' DDE. It basically polls for a LabVIEW DDE service and if that succeeds will pass any possible command line parameters to that service and terminate itself. Why DDE? Because that is the mechanisme the Windows File Manager used to pass parameters to executable files and even modern Windows Explorer does still do this if the application is not a (D)COM server.

So if DDE is somehow disabled or otherwise troubled you could see this situation.

[MichaelS78]

I have this situation on 11 machines, all running different applications! I had a support request open with NI for several weeks two years ago and it was never resolved.  Even now I build in my own checks in my applications.  All of these applications run in the same win10 iot ent ltsb build with LabVIEW 2018 32 bit.  However many times I asked NI would not tell me how LabVIEW checks for running instances.  Thanks @RolfK I now have an avenue to go down once again.  I had to send NI a video before they would believe this happens, so it must be a very unusual situation.

[RavensFan]

Since it is an IoT version of Win10, I wonder if the problem lies there.  Perhaps whatever mechanism NI relies on for limiting .exe instances doesn't exist in IoT since it is a reduced version of regular Win10?

[rolfk]

---

@RavensFan wrote:

Since it is an IoT version of Win10, I wonder if the problem lies there.  Perhaps whatever mechanism NI relies on for limiting .exe instances doesn't exist in IoT since it is a reduced version of regular Win10?

---

It could make sense. DDE is VERY much legacy technology (I mean OLE was meant to replace it, ActiveX was a more standardized version of OLE/COM and then Microsoft sort of depreciated even that in favor of .Net) and there might be reason Microsoft simply whacked it from the IoT version for whatever reason. All but the IoT Enterprise versions won't even run LabVIEW as they do not support the classic Win32 Subsystem but require all apps to be UWP compliant, meaning they need to be compiled to use the .Net API instead (and only can install from the Windows Store unless you are willing to put your system into a special debug mode).