Preventing Multiple Instances of a Windows App — Named Mutexes and Activating the Existing Window on a Second Launch

“I accidentally launched the business app a second time, ended up editing the same file in two separate windows, and lost the changes from one of them.” “A background tool started up twice and ended up double-processing the same event.” Multiple launches of a desktop app sound like a minor topic, but in practice they’re a surprisingly common source of incidents. The core countermeasure itself is simple: use a named Mutex to determine “am I the first instance.”

The trouble is that this simple implementation comes with a set of surrounding pitfalls: a namespace trap that disables the protection in Remote Desktop environments, release rules specific to Mutex that differ from other synchronization objects, and the design question of how to bring an already-running instance to the foreground, which runs into Win32’s foreground-window restrictions. This article works through everything from the basics of detecting multiple launches with a named Mutex to the surrounding design decisions that actually matter in production.

1. The Short Version

• The basic form of multiple-launch detection is new Mutex(true, name, out bool createdNew). No exception is thrown even if a Mutex with the same name already exists — createdNew simply comes back false, so you branch on that value.¹
• If you don’t prefix the name, it’s created by default in the Local\ (session-scoped) namespace. In a Remote Desktop environment where the same user can have multiple sessions, each session gets treated as having its own separate Mutex, and multiple-launch prevention doesn’t work. If you want a single instance across sessions, the Global\ prefix is mandatory.²³
• A Mutex can only be released by the same thread that acquired it. Calling ReleaseMutex from a different thread throws ApplicationException. If the owning process terminates without releasing it, the next thread to acquire the Mutex receives an AbandonedMutexException — but this is actually a signal that the wait itself succeeded, and the correct way to handle it is to check the consistency of state before use, not swallow it silently.⁴⁵
• Once you know “an instance is already running,” the real work is bringing the existing instance’s window to the front. SetForegroundWindow is restricted by the OS to callers other than the foreground process, so calling it naively fails and you end up with nothing more than a flashing taskbar button.⁶ The standard technique is to have the newly launched second process hand off its own “permission to set the foreground” to the existing instance via AllowSetForegroundWindow.⁷
• To pass launch arguments (such as a file path to open) to the existing instance, forwarding them over a named pipe is the standard approach. We leave the comparison of IPC mechanisms to “How to Choose Windows Inter-Process Communication” and focus this article on the “detect → notify → activate” design.
• Console apps and services aren’t a direct fit for the design in this article. Services work differently from the start, because the SCM only ever starts one instance of a given service name in the first place (Chapter 8).

2. The Basics of Detection with a Named Mutex

A Mutex is a kernel object; if you create it with a name, other processes that know that name can reference the same object. Multiple-launch detection relies solely on this “name sharing.”

using var mutex = new Mutex(initiallyOwned: true, name: MutexName, out bool createdNew);
if (!createdNew)
{
    // Already running
    return;
}
// This thread owns the Mutex only when createdNew is true

Two points are worth keeping in mind here.

• No exception is thrown even if a Mutex with the same name already exists. createdNew simply comes back false, and you get back a reference to the existing object. Always branch on createdNew.¹
• initiallyOwned: true only takes effect when a new object could actually be created. If one already existed (createdNew == false), this thread does not automatically become the owner. That side effect doesn’t matter for multiple-launch detection, but to prevent the accident of “the second process mistakenly calls ReleaseMutex,” it’s safest for the branch where createdNew is false to not touch the Mutex at all and simply finish immediately.¹

The standard practice for the name is to embed a product-specific GUID so it doesn’t collide with other vendors’ apps (e.g. "KomuraSoft.MyApp.SingleInstance.{3F1E2B10-...}"). Just like pipe-name squatting, the namespace for named kernel objects is visible to other processes on the machine, so there’s value in making the name hard to guess.

3. Global\ vs. Local\ — What Happens Across Sessions

Windows kernel object namespaces are split between per-session namespaces and a single global namespace shared across the whole system. When you create a named Mutex without specifying a prefix, it is created by default in the caller’s session namespace (Local\); only if you add Global\ is it created in the namespace shared across all sessions.³ The .NET Mutex class follows this same behavior, and its documentation explicitly states that “a named Mutex without a prefix defaults to Local\.”²

This becomes a problem in scenarios like these:

• A user logs into a business admin machine directly from the console, while also connecting to that same machine via Remote Desktop as another session for themselves (this is common in operations).
• The same user repeatedly disconnects and reconnects an RDP session, and each reconnection is assigned a new session ID.

If you leave the Mutex as Local\ (no prefix), these cases are treated as separate sessions, and multiple-launch prevention operates independently in each session. In other words, you get the bug of “the same user can launch a second copy just fine from a second session” — multiple-launch prevention doesn’t work as intended. Conversely, for ordinary desktop use that assumes only a single session, staying with Local\ (the default) causes no real harm.

The general design of machines shared by multiple users is also covered in “Introduction to Windows User Profiles,” but focusing specifically on this article’s topic, caution is needed. Global\ is a single namespace shared by every user and every session on the machine — it does not automatically mean “one instance per user.” If you just add Global\ while keeping the name fixed, e.g. Global\KomuraSoft.MyApp.SingleInstance, then while user A is running the app, user B’s launch attempt is blocked by the very same Mutex too — effectively giving you “one instance for the entire machine” (row 3 of the table in Chapter 5). If what you want is “one instance per user, but consolidated across that user’s multiple sessions,” you need to combine Global\ with a user-specific identifier (such as a SID) embedded in the name. Conversely, if you actually want to restrict to a single instance for the whole machine (all-users-shared behavior is intentional), keeping Global\ without a SID is fine.

4. Mutex Release Rules — Owning Threads and AbandonedMutexException

Mutex has a constraint that other synchronization objects like Semaphore and AutoResetEvent don’t have: it enforces the thread ID that acquired it, meaning it can only be released by the same thread that acquired it.² Calling ReleaseMutex from a different thread throws ApplicationException (“the calling thread does not own the mutex”).⁴

In code that uses async/await, execution can resume on a different thread-pool thread after an await. Be careful: writing code that acquires a Mutex and then, right after inserting some asynchronous work, releases it in the continuation can quietly violate this constraint. For multiple-launch detection, it’s safest to keep both acquisition and release inside short, synchronous code.

Another point to watch is abandonment. If the thread that owned a Mutex terminates without calling ReleaseMutex (the process crashed, it died from an unhandled exception, etc.), that Mutex ends up in an abandoned state. The next thread that acquires this Mutex receives an AbandonedMutexException, but this exception actually indicates that the wait itself succeeded, and the caller already holds ownership of the Mutex.⁵ This typically doesn’t come up for pure multiple-launch detection (since you acquire it and hold it, without releasing it, until the process exits), but if you’re reusing the same Mutex for other mutual-exclusion purposes as well, you should handle it as follows, keeping in mind that the state you were protecting may have been left inconsistent:

try
{
    if (mutex.WaitOne(TimeSpan.FromSeconds(5)))
    {
        // Normal processing
    }
}
catch (AbandonedMutexException)
{
    // The wait succeeded, and this thread already owns the mutex.
    // Inspect the protected state before using it, or re-initialize it safely
}

The judgment of “ignore the exception, inspect state and continue, or give up and terminate abnormally” maps directly onto the thinking in this blog’s “Decision Table: Exit or Continue on Unexpected Exceptions.” AbandonedMutexException is an exception that explicitly tells you “the range that may be broken,” so the basic policy is to inspect just that range (the protected data) rather than swallow the exception.

Also, on the normal-exit path, you should call ReleaseMutex explicitly in a finally block. When the owning thread disappears as the process terminates, the Mutex is treated as “abandoned,” so if you don’t release it explicitly you’ll cause a needless AbandonedMutexException the next time the app starts.

5. Decision Table — Choosing the Scope for Your Mutex

The namespace and pipe-side design change depending on the “unit” at which you want to prevent multiple launches.

As a supplementary note, named pipes are not subject to Local\/Global\ session namespacing the way Mutex is, and by default they’re reachable across sessions. In other words, even without CurrentUserOnly, as long as the pipe name matches, the connection itself will reach an existing instance in a different session. Here, CurrentUserOnly isn’t about reachability but about authorization — it’s an access control that narrows down “whose connections to allow” to the current user (and the same elevation level). If you don’t set it, the default security descriptor grants read access to Everyone too, so connections from unintended other users would get through as well. In a design that achieves “per user, across sessions” using a Global\ + SID Mutex, it’s appropriate to also add CurrentUserOnly to the notification pipe, narrowing the connecting party to the same “target user only” as the Mutex. Fortunately, PipeOptions.CurrentUserOnly is judged by the user’s SID (and elevation level) rather than the session ID, so it composes cleanly with row 2 of the table above (per user, across sessions).

One more thing: if you use a fixed-name Global\ Mutex for the per-machine case (row 3 of the table), you also need to watch out for name squatting. If you’re trying to restrict an app to a single instance using a named Mutex, a malicious user could preemptively create a Mutex with the same name and interfere with the app’s launch.⁸ Setting an explicit ACL at creation time via MutexSecurity (MutexAcl.Create) protects against another user hijacking or improperly holding onto the Mutex once you have managed to create it first. Note, however, that this is a defense against “being interfered with afterward” — it does nothing to prevent “being squatted on first” in the first place. The ACL only takes effect once you newly create the Mutex, so if a malicious user has already created a Mutex under the same name before you, your call (however elaborate an ACL you prepare) just ends up opening the existing object they set up, and you’re stuck with whatever ACL they configured. Having a name that’s hard to guess in the first place does have some value on its own, but if you want to fully shut out a malicious user with local code-execution rights, don’t rely solely on Mutex name occupation — consider combining it with another exclusion mechanism, such as a lock file under a directory protected per user.⁹

One more point: CurrentUserOnly has an easily overlooked constraint. On Windows, it only allows a connection if not just the user account matches, but also the elevation level (whether you’re running as administrator) matches.¹⁰ It’s tempting to assume that “since the Mutex’s name is built solely from the user’s SID, detection itself works regardless of elevation” — but when you use a Mutex with an explicit ACL, elevation affects this too. By default, Windows attaches a high integrity level label to objects created by a process running at a high integrity level (running as administrator), and denies write-type access from processes at a lower integrity level. .NET’s Mutex/MutexAcl.Create internally requests, on top of SYNCHRONIZE and MUTEX_MODIFY_STATE, also DELETE/READ_CONTROL/WRITE_DAC/WRITE_OWNER (STANDARD_RIGHTS_REQUIRED), so if you launch the first instance “as administrator” and then launch a second instance with normal privileges, the Mutex creation/open call itself can throw UnauthorizedAccessException. In other words, the premise from Chapter 7 that “only the notification pipe gets rejected by the ACL, while multiple-launch prevention itself succeeds” can break down, and an exception can be thrown earlier, before detection even happens. Treat this path too as a signal that “another instance is already running, or the elevation level differs, so it can’t be determined by the normal means” — it’s appropriate to wrap the Mutex/MutexAcl.Create call itself in try/catch (UnauthorizedAccessException) and, on exception, give up on launching and exit quietly (or, similar to “it’s fine if the notification doesn’t arrive” in Chapter 7, err on the safe side for multiple-launch prevention). If you need notification across elevation levels too, switch away from CurrentUserOnly to a design that explicitly builds a SID-based ACL via PipeSecurity.

6. Bringing the Existing Instance to the Front — SetForegroundWindow Restrictions

Once you’ve determined via Mutex that “an instance is already running,” most apps will want to bring the existing instance’s window to the front. Simply calling SetForegroundWindow against the existing process will, in most cases, fail.

Windows tightly restricts which processes can set the foreground window. According to the official documentation, unless the calling process satisfies one of the following, SetForegroundWindow does not actually bring the window to the front — it just flashes the taskbar button.⁶

• The calling process itself is the current foreground process
• The calling process was launched by the foreground process
• The calling process received the most recent input event
• There is currently no foreground window
• The foreground process, or the calling process, is being debugged

In the multiple-launch detection scenario, the existing instance (the first process, running in the background) typically doesn’t satisfy any of these conditions. On the other hand, the second process the user just double-clicked to launch has, in many cases, just received an input event and holds the permission to set the foreground. Exploiting this asymmetry is the standard practice in production.

AllowSetForegroundWindow is an API that lets a process that can set the foreground hand that permission over to another process.⁷ If the second process gives up its own permission with ASFW_ANY (granting it to all processes) and then requests activation from the existing instance over a named pipe, the existing instance’s SetForegroundWindow call will succeed.

[DllImport("user32.dll")]
private static extern bool AllowSetForegroundWindow(int dwProcessId);

private const int ASFW_ANY = -1;

// Assuming the second process (this one) holds foreground-setting permission,
// hand it over unconditionally. This lets the SetForegroundWindow call
// on the existing instance's side succeed
AllowSetForegroundWindow(ASFW_ANY);

There remain cases even this can’t save (such as a launch via Task Scheduler, where the second process itself has no foreground permission either). In those cases, a reasonable design is to stop at notifying via the flashing taskbar and not force the window to the front. As user notification, it’s fine to always use a toast notification and restore WindowState from Minimized to Normal, while treating the final “bring to front” step as a “do it if you can” nicety rather than something that must succeed.

7. Passing Launch Arguments to the Existing Instance — Named Pipes

Beyond just detecting multiple launches, it’s also a common requirement that “if you launch the app with a file to open as an argument, the existing instance should open that file.” WM_COPYDATA (the classic mechanism of sending data via a window message) exists as an option for this purpose too, but the hassle of obtaining a window handle and marshaling the message outweighs what you gain, so for new designs it’s more straightforward to use a named pipe.

The design is simple: the second process, which has determined via the Mutex that “an instance is already running,” connects to the named pipe the existing instance is listening on and sends the command-line arguments serialized as, say, JSON. Implementation caveats specific to named pipes themselves — countering pipe-name squatting, access control via CurrentUserOnly, and so on — are covered in the named-pipes section of “How to Choose Windows Inter-Process Communication,” so follow that. The only caveat specific to the multiple-launch-detection context is the following:

• If sending the notification fails, that’s still fine to treat as a success for multiple-launch prevention. There are timing issues where the notification doesn’t get through, such as the existing instance being in the middle of shutting down and having closed its pipe server. Even so, the primary goal — “don’t let the second process launch” — has still been achieved, so there’s no need to show an error dialog just because the notification failed.

8. How This Differs for Console Apps and Services

The design in this article assumes a desktop app that has a window. For console apps and batch tools, it’s often more realistic to design for “coexisting safely even when run multiple times at once” rather than “preventing multiple launches,” which effectively reduces to the question of file-integration exclusion control.

Windows services are a different matter altogether. Because the Service Control Manager (SCM) never starts two instances of a service with the same name in the first place, the Mutex-based detection in this article is basically unnecessary. In configurations like “a UI app plus a resident service,” you’d use this article’s design only for the UI side; how to think about multiple launches/executions on the service side is a separate topic. We leave how to build a service, and its design considerations, to another article.

9. Implementation Example — Detection and Activation Request via Mutex

This is a practical, minimal setup that ties together the content of Chapters 2 through 7. It assumes WPF, but it works almost as-is for WinForms too, just by swapping Application.Current.Dispatcher for Control.Invoke.

using System.IO.Pipes;
using System.Runtime.InteropServices;
using System.Security.AccessControl;
using System.Security.Principal;
using System.Text.Json;

public static class Program
{
    // Embed a product-specific GUID so the name doesn't collide with other apps.
    // Since we want to restrict to a single instance "per user, across sessions,"
    // we embed the user's SID in the name in addition to Global\. If you use
    // Global\ alone without the SID, all users end up sharing the same Mutex,
    // which turns into "one instance for the entire machine" (Chapter 3)
    private static readonly string MutexName =
        $@"Global\KomuraSoft.MyApp.SingleInstance.{{3F1E2B10-9C2E-4B7E-8B1E-8B4F2D6A5C10}}.{WindowsIdentity.GetCurrent().User}";
    // Align the notification pipe's scope with the Mutex's (per-user). If we
    // keep a fixed name without the SID, this can collide/cross-talk when a
    // different user stands up a server under the same name
    // (Chapter 5; CurrentUserOnly only narrows the ACL, it doesn't separate names)
    private static readonly string PipeName =
        $"KomuraSoft.MyApp.Activate.{{3F1E2B10-9C2E-4B7E-8B1E-8B4F2D6A5C10}}.{WindowsIdentity.GetCurrent().User}";

    [STAThread]
    private static void Main(string[] args)
    {
        // Setting an explicit ACL that grants full control only to the current
        // user prevents hijacking/interference from other users, once we've
        // managed to create it first (requires the NuGet package
        // System.Threading.AccessControl). This does not, however, defend
        // against being squatted on first (Chapter 5)
        var mutexSecurity = new MutexSecurity();
        mutexSecurity.AddAccessRule(new MutexAccessRule(
            WindowsIdentity.GetCurrent().User!, MutexRights.FullControl, AccessControlType.Allow));

        bool createdNew;
        Mutex mutex;
        try
        {
            // This call only actually acquires the Mutex when createdNew is true
            mutex = MutexAcl.Create(
                initiallyOwned: true, name: MutexName, createdNew: out createdNew, mutexSecurity: mutexSecurity);
        }
        catch (UnauthorizedAccessException)
        {
            // Even for the same user, a mismatched elevation level can cause the
            // open of an existing Mutex itself to be denied (Chapter 5). Treat
            // this as "another instance at a different elevation level already
            // exists," give up on notifying, and err on the safe side (don't launch)
            return;
        }
        using var _ = mutex;

        if (!createdNew)
        {
            // Already running. Notify the existing instance and exit ourselves
            NotifyRunningInstanceAsync(args).GetAwaiter().GetResult();
            return;
        }

        try
        {
            // Make sure App.xaml's StartupUri has been removed. If left in place,
            // the StartupUri-based window gets auto-created and shown in addition
            // to the MainWindow we build manually here (overwriting app.MainWindow
            // too), leaving two windows open, with the activation request possibly
            // ending up pointed at the wrong one
            var app = new App();
            app.InitializeComponent();
            var mainWindow = new MainWindow();
            app.MainWindow = mainWindow;
            mainWindow.Show();

            // Start the pipe server only after MainWindow has been created and
            // shown. Doing it in the reverse order risks an activation request
            // arriving before the window exists, which can make the
            // ActivateMainWindow call fail (the exception gets swallowed by the
            // catch-all below, so the notification simply disappears). A request
            // that arrives during this window falls back to the best-effort
            // design in NotifyRunningInstanceAsync ("server not started yet ->
            // connection failure", Chapter 7)
            StartActivationServer();

            app.Run();
        }
        finally
        {
            // Release explicitly from the owning thread (this thread) before
            // exiting. Failing to release before exit causes a needless
            // AbandonedMutexException on the next launch (Chapter 4)
            mutex.ReleaseMutex();
        }
    }

    private const int ASFW_ANY = -1;

    [DllImport("user32.dll")]
    private static extern bool AllowSetForegroundWindow(int dwProcessId);

    private static async Task NotifyRunningInstanceAsync(string[] args)
    {
        try
        {
            using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(3));
            using var pipe = new NamedPipeClientStream(
                ".", PipeName, PipeDirection.Out, PipeOptions.Asynchronous | PipeOptions.CurrentUserOnly);
            await pipe.ConnectAsync(cts.Token);

            // We (the second process, just launched) have likely just received an
            // input event and often hold foreground-setting permission. Hand that
            // permission over unconditionally so the existing instance's
            // SetForegroundWindow call succeeds (Chapter 6)
            AllowSetForegroundWindow(ASFW_ANY);

            byte[] payload = JsonSerializer.SerializeToUtf8Bytes(new ActivateRequest(1, args));
            await pipe.WriteAsync(payload, cts.Token);
        }
        catch (Exception ex) when (ex is IOException or UnauthorizedAccessException or OperationCanceledException)
        {
            // Whether it's the existing instance not responding because it was
            // shutting down (IOException), or CurrentUserOnly authorization
            // failing due to a mismatched elevation level
            // (UnauthorizedAccessException; see the note in Chapter 5), we don't
            // distinguish the reason the notification failed to arrive — the
            // primary goal of multiple-launch prevention (don't let the second
            // one launch) has still been achieved (Chapter 7)
        }
    }

    private static void StartActivationServer()
    {
        // Upper bound on a single message. Protects the server's memory even if
        // a stale helper from the same user, or a broken client, keeps sending
        // indefinitely
        const int MaxPayloadBytes = 64 * 1024;

        _ = Task.Run(async () =>
        {
            while (true)
            {
                try
                {
                    // Put the constructor itself inside the try too. Because
                    // maxNumberOfServerInstances is 1, this can throw IOException
                    // at a moment when cleanup from the previous connection
                    // hasn't finished yet; placing it outside the try would let
                    // this single failure kill the entire background task
                    using var pipe = new NamedPipeServerStream(
                        PipeName, PipeDirection.In, 1,
                        PipeTransmissionMode.Byte, PipeOptions.Asynchronous | PipeOptions.CurrentUserOnly);

                    await pipe.WaitForConnectionAsync();

                    // Since maxNumberOfServerInstances is 1, if this connection
                    // gets stuck on an unresponsive client, we'd be unable to
                    // accept any further legitimate launch requests at all.
                    // Impose a time limit on a single connection
                    using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
                    using var ms = new MemoryStream();
                    var buffer = new byte[4096];
                    int n;
                    while ((n = await pipe.ReadAsync(buffer, cts.Token)) > 0)
                    {
                        ms.Write(buffer, 0, n);
                        if (ms.Length > MaxPayloadBytes)
                            throw new IOException("Payload exceeded the maximum size.");
                    }

                    var req = JsonSerializer.Deserialize<ActivateRequest>(ms.ToArray());
                    // Validate Args as well as Version. An old-version sender, or
                    // a hand-crafted malformed payload, might send JSON like
                    // {"Version":1} that's missing Args, which deserializes with
                    // Args left null
                    if (req is { Version: 1, Args: not null })
                    {
                        // Perform UI operations back on the UI thread
                        Application.Current.Dispatcher.Invoke(() => ActivateMainWindow(req.Args));
                    }
                }
                catch (Exception)
                {
                    // Swallow this as a failure of this single connection,
                    // regardless of the reason — a dropped connection, exceeding
                    // the time or size limit, a corrupted payload, an unexpected
                    // exception during dispatch, etc. Since letting this task
                    // itself die would mean we can no longer accept any further
                    // notifications, the loop must always continue. That said, to
                    // avoid hot-spinning in the case where constructing the pipe
                    // itself keeps failing immediately before the await (e.g.
                    // another process holds the single-instance slot), always
                    // take a breather before the next loop iteration
                    await Task.Delay(TimeSpan.FromSeconds(1));
                }
            }
        });
    }

    [DllImport("user32.dll")]
    private static extern bool SetForegroundWindow(IntPtr hWnd);

    private static void ActivateMainWindow(string[] args)
    {
        var window = Application.Current.MainWindow;
        if (window is null) return;

        if (window.WindowState == System.Windows.WindowState.Minimized)
            window.WindowState = System.Windows.WindowState.Normal;
        window.Show();
        window.Activate();

        // WPF's Activate() calls SetForegroundWindow internally, but it can fail
        // due to the restriction (Chapter 6), so call it explicitly too, now that
        // AllowSetForegroundWindow has already been granted
        var hwnd = new System.Windows.Interop.WindowInteropHelper(window).Handle;
        SetForegroundWindow(hwnd);

        if (args.Length > 0)
        {
            // Treat args[0] as the file path to open, or other app-specific handling
        }
    }

    private sealed record ActivateRequest(int Version, string[] Args);
}

Three design decisions worth calling out:

• Choose a user identifier to append to Global\ that doesn’t change over time. The SecurityIdentifier returned by WindowsIdentity.GetCurrent().User, unlike a username, isn’t affected by renames, and ToString() gives you a string in the S-1-5-21-... format.¹¹ Embedding the username directly can lead to the accident of multiple-launch prevention breaking after an account rename or a domain migration.
• Explicitly release the Mutex and stop the pipe server as part of the app’s shutdown process. In the example above we call ReleaseMutex in a finally block, but in a real app you should also stop the pipe server’s loop using a cancellation token as part of the window-closing logic.
• Include a version field from the start. There’s a reasonable chance you’ll change the format of launch arguments in the future. Building in a “unknown versions are ignored” check from the beginning lets you behave safely even on a machine where an older version of the executable is still around.

10. Summary

Preventing multiple launches of a Windows app looks simple if you only look at the few lines of new Mutex(true, name, out createdNew). But to make it work in production without incidents, you need a full grasp of the surrounding knowledge: the difference in session visibility between Global\ and Local\, the thread-ownership constraint unique to Mutex and how to handle AbandonedMutexException, and an activation design that accounts for SetForegroundWindow’s restrictions.

As for implementation order: first decide “at what unit (session, user, or machine) you want to prevent multiple launches” (Chapter 5), and align the Mutex’s namespace and the notification pipe’s scope accordingly. From there, use the standard technique of delegating permission via AllowSetForegroundWindow to bring the existing instance to the front, and accept that in cases where that still fails, you settle for a notification rather than forcing the window to the front — with that mindset in place, the implementation won’t fall apart. If you’re unsure whether the requirement is “one instance per user” or “one instance for the whole machine,” we’d recommend first confirming the operating environment (whether RDP is combined with console use, whether multiple users log on simultaneously).

Related Articles

• How to Choose Windows Inter-Process Communication — A Decision Table for Named Pipes / TCP / gRPC / Shared Memory / COM
• Introduction to Windows User Profiles - AppData and NTUSER.DAT
• Decision Table: Exit or Continue on Unexpected Exceptions

Related Consulting Areas

KomuraSoft LLC handles the design and implementation of Windows desktop apps — including multiple-launch prevention and window control — investigating issues specific to Remote Desktop environments, and design reviews of existing apps.

• Windows App Development
• Technical Consulting & Design Review
• Bug Investigation & Root Cause Analysis
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.