Introduction

WPF does not provide a dedicated restart method because restarting is really a process-management task, not a UI feature. In practice, restarting means starting a new copy of the current executable and then shutting down the existing application cleanly.

The Basic Restart Pattern

A reliable restart flow has three steps:

1. Find the current executable path.
2. Launch a new process for that executable.
3. Close the current application.

In current .NET versions, Environment.ProcessPath is the simplest way to locate the running executable.

1using System;
2using System.Diagnostics;
3using System.Windows;
4
5public static class AppRestarter
6{
7    public static void Restart()
8    {
9        string? exePath = Environment.ProcessPath;
10        if (string.IsNullOrWhiteSpace(exePath))
11            throw new InvalidOperationException("Could not determine process path.");
12
13        Process.Start(new ProcessStartInfo(exePath)
14        {
15            UseShellExecute = true
16        });
17
18        Application.Current.Shutdown();
19    }
20}

You can call AppRestarter.Restart() from a menu command, a settings screen, or an update workflow.

Preserving Command-Line Arguments

Some desktop applications rely on startup arguments for mode selection, file opening, or diagnostics. If the current process was started with arguments, you may want the new process to inherit them.

1using System;
2using System.Diagnostics;
3using System.Linq;
4using System.Windows;
5
6public static class AppRestarter
7{
8    public static void RestartPreservingArguments()
9    {
10        string? exePath = Environment.ProcessPath;
11        if (string.IsNullOrWhiteSpace(exePath))
12            throw new InvalidOperationException("Could not determine process path.");
13
14        string arguments = string.Join(" ", Environment
15            .GetCommandLineArgs()
16            .Skip(1)
17            .Select(Quote));
18
19        Process.Start(new ProcessStartInfo(exePath, arguments)
20        {
21            UseShellExecute = true
22        });
23
24        Application.Current.Shutdown();
25    }
26
27    private static string Quote(string value)
28    {
29        return value.Contains(' ') ? $"\"{value}\"" : value;
30    }
31}

This is especially useful if your application supports file associations or launches into specific workspaces.

Save State Before Restarting

Many restart flows exist because settings only take effect after startup. When that is the case, save state before launching the replacement process.

1using System.Diagnostics;
2using System.Windows;
3
4private void ApplyThemeAndRestart()
5{
6    Properties.Settings.Default.ThemeName = "Dark";
7    Properties.Settings.Default.Save();
8
9    Process.Start(new ProcessStartInfo(Environment.ProcessPath!)
10    {
11        UseShellExecute = true
12    });
13
14    Application.Current.Shutdown();
15}

Without the save step, the application restarts correctly but the requested configuration never takes effect.

Restarting from Background Work

If a background task discovers that a restart is required, finish the process launch and shutdown on the UI thread. WPF application lifetime is UI-centered, so doing the final shutdown from the dispatcher is safer.

1using System.Diagnostics;
2using System.Windows;
3
4Application.Current.Dispatcher.Invoke(() =>
5{
6    Process.Start(new ProcessStartInfo(Environment.ProcessPath!)
7    {
8        UseShellExecute = true
9    });
10
11    Application.Current.Shutdown();
12});

This keeps the restart aligned with normal WPF threading rules.

Single-Instance Applications Need Extra Care

If your app uses a mutex or another single-instance guard, the new process can start before the old one fully exits. The result is a failed restart where the replacement instance immediately quits.

There are a few ways to handle that:

• release the single-instance lock before shutdown
• delay the relaunch slightly
• use a bootstrapper or updater process to perform the handoff

A helper process is common in auto-update systems because it can wait until the main app exits, replace files if necessary, and then start the new version cleanly.

Why the Order Matters

Always start the new process before shutting down the current one. If you close first, the restart code may never run to completion, especially if shutdown triggers cleanup logic or window teardown that stops later instructions.

The start-then-shutdown order also makes debugging easier because you can confirm that Process.Start succeeded before the app exits.

Common Pitfalls

The most common mistake is shutting down before starting the replacement process. That can leave the user with a closed application and no restart.

Another issue is forgetting to save settings, temporary files, or unsent work before restart. If restart is user-visible, treat it like a controlled shutdown.

Developers also sometimes use assembly metadata to locate the executable, which may not match the real deployed process path in all hosting setups. Environment.ProcessPath is usually a better fit on modern .NET.

Finally, single-instance protections can block the new process unless you coordinate the handoff carefully.

Summary

• Restarting WPF means launching a new process and then calling Shutdown.
• 'Environment.ProcessPath is the easiest way to locate the current executable.'
• Preserve command-line arguments when startup behavior depends on them.
• Save settings before restart so changes survive the relaunch.
• Watch for single-instance locks that can block the replacement process.