How to use CheckForDuplicateAppInstance() across different contexts

[Sandia_Mike]

Trying to avoid duplicate instances of my LabWindows/CVI application.  The first instance was run using Task Scheduler before user logon with the option, "Run whether user is logged on or not".  Apparently CheckForDuplicateAppInstance() cannot detect an instance from a different context, because users can run a second instance (but not a third). A second instance creates resource conflicts when devices are accessed during data collection.

The other issue is the Task Scheduler instance does not display the user interface after logon.  This encourages users to run a second instance because the first is not visible, and also makes stopping the application impossible without rebooting the machine.  When a user attempts to start a second instance, would like to bring the user interface to the current context and but not run a second instance.  Running Windows 11, CVI 2015.

[gdargaud]

Hi Mike,

I think that's a complex problem.

As for checking duplicate instances in various contexes, why don't you simply check the availability of your unsharable resource on start ? If not available -> probably already running.

As for your 2nd question, I don't know if you can recover a graphical app that was started headless, particularly by a different user (*) ! But the usual solution for this kind of problem is to split your app in 2: one part is a headless unique service that does the acquisition and saves files and communicates with other programs via sockets (or other), and the 2nd is the graphical part that can be run in multiple instances (including on remote systems).

(*) on Linux X11 it *is* possible but quite tricky to do. You can even move an entire running process to a different system while it is running. I've done it and it is magical !

[rolfk]

Applications started before a user has logged on to a machine, including services, are started in session0 of the Windows session manager. Sessions are highly isolated environments that allow only very limited interaction to applications in other sessions, really mainly limited to standard Interapplication Communication (IAC) measure such as network communication.

That's the reason the CheckForDuplicateAppInstance() can not detect your already running instance. It is for most technical purposes as if it would run on a different machine.

session0 has another limitation: It has no UI and processes running inside it have no possibility to access an UI. For one there is no UI session before a user has logged in, and while older Windows versions did allow UI interaction from processes running in session0 after a user had logged in, this was truly disabled and actively prevented since Windows 10, and for a lesser degree Windows Vista, for security reason.

https://techcommunity.microsoft.com/blog/askperf/application-compatibility---session-0-isolation/372...

The only way to solve both issues is by actually implementing some form of IAC. For instance you can register a TCP/IP server instance that then answers to requests about whatever information you want to have available to a desktop session of your application.

When you start your application try to connect to that server, of it succeeds you are a secondary instance and you can detect in which session you are running by calling the Windows API ProcessIdToSessionId() and check it with the session of the instance you connected to. If it is the same your application is already running and you can quit. If it is not the same your application is also already running but in a different session context (likely your non interactive session0 instance started through TaskScheduler). In this case your application should be just acting as UI to the actual application running in the non-interactive session and relay the information it queries from that instance through the TCP/IP connection to the actual user.

[Sandia_Mike · Accepted solution]

Thanks to you both!  Seems I don't know nothin' about nothin'.  I'll see if the IT folks will allow using the Task Scheduler to Auto login before I start the LabWindows app.  Since the users post the password on the machine, not really a degradation of security.