Introduction

If you want only one copy of a desktop .NET application to run at a time, the standard solution is a named mutex. It works across processes, is supported directly by the framework, and is much more reliable than checking process names or window titles.

Why a Named Mutex Is the Usual Answer

A single-instance app needs one process-wide lock that every new launch attempt checks before continuing. A named mutex gives you exactly that.

The basic idea is:

1. create or open a mutex with a fixed name
2. detect whether your process created it first
3. if not, exit or signal the existing instance

A minimal console or WinForms-style example looks like this:

1using System;
2using System.Threading;
3
4class Program
5{
6    [STAThread]
7    static void Main()
8    {
9        using var mutex = new Mutex(true, "MyCompany.MyApp", out bool createdNew);
10
11        if (!createdNew)
12        {
13            Console.WriteLine("Application is already running.");
14            return;
15        }
16
17        Console.WriteLine("First instance running. Press Enter to exit.");
18        Console.ReadLine();
19    }
20}

If createdNew is false, another instance already owns that mutex name.

Choose the Mutex Scope Carefully

The mutex name decides how broad the single-instance rule is.

• 'MyCompany.MyApp is usually enough for a per-machine name'
• 'Global\MyCompany.MyApp makes the intent explicit across terminal sessions on Windows'
• a user-specific suffix can limit the rule to one instance per logged-in user

That choice matters. Some apps want one instance for the whole machine, while others want one instance per user session.

WPF and WinForms Integration

In a WPF app, the mutex check often belongs near startup before the main window appears.

1using System.Threading;
2using System.Windows;
3
4public partial class App : Application
5{
6    private Mutex? _mutex;
7
8    protected override void OnStartup(StartupEventArgs e)
9    {
10        _mutex = new Mutex(true, "MyCompany.MyWpfApp", out bool createdNew);
11
12        if (!createdNew)
13        {
14            Shutdown();
15            return;
16        }
17
18        base.OnStartup(e);
19    }
20}

This prevents the second instance from building the full UI only to realize too late that it should quit.

Bringing the Existing Window to the Front

Preventing the second instance is only half the problem. Good desktop UX often also brings the already-running window forward.

That usually requires inter-process communication such as:

• named pipes
• a local TCP endpoint
• Windows messages for classic desktop apps

The second instance detects the mutex, sends a “show yourself” signal to the first instance, and then exits. The mutex still provides the single-instance guarantee; IPC adds the user-facing polish.

Why Process Enumeration Is Weaker

Checking Process.GetProcessesByName(...) looks tempting, but it is weaker than a mutex. Process names can collide, races are easier, and the logic becomes fragile across renamed executables or multiple install paths.

A named mutex is simpler and more explicit.

Common Pitfalls

The biggest mistake is forgetting that the mutex object must stay alive for the lifetime of the application. If you create it in a short-lived scope and let it be disposed too early, another instance can start.

Another mistake is using an overly generic name that collides with another app or test harness.

A third mistake is assuming “single instance” automatically means the existing window gains focus. That requires extra signaling logic.

Summary

• Use a named mutex to prevent multiple .NET app instances.
• Check the createdNew flag and exit early in the second instance.
• Keep the mutex alive for the full application lifetime.
• Decide whether the rule is per machine, per user, or per session.
• Add IPC only if you also want the existing instance to bring its window forward.