The WPF Application Lifecycle

A WPF application's lifecycle starts before any of your code runs: the compiler generates a Main() method that constructs the App object, calls its auto-generated InitializeComponent() (which merges the resources declared in App.xaml), and then calls Application.Run(), which starts the message loop and, if StartupUri is set, creates and shows that window. From there the app lives inside that message loop, dispatching input, layout, and render work until something calls Application.Shutdown() or the last window closes, at which point the Exit event fires and the process winds down.

The Startup event, or overriding OnStartup(StartupEventArgs e) in App.xaml.cs, is where you run logic that needs to happen before the main UI appears — reading command-line arguments from e.Args, configuring a dependency-injection container, checking for a required config file, or deciding which window to show based on runtime conditions. If you need that kind of conditional logic, it's common to remove StartupUri from App.xaml entirely and instead construct and Show() the chosen window manually inside OnStartup, giving you full control over what the user sees first instead of relying on a fixed XAML attribute.

WPF UI runs on a single-threaded apartment: the thread that creates a window also owns its Dispatcher, and every DispatcherObject-derived UI element (which is nearly all of them) can only be touched safely from that owning thread. The Dispatcher itself maintains a priority queue of work items — input events, layout passes, render operations, and any code you've queued — and processes them roughly in priority order as part of the message loop that Application.Run() started; if a background thread (say, one doing an HTTP call or heavy computation) needs to update a UI element, it must marshal that call back onto the UI thread via Dispatcher.Invoke or Dispatcher.BeginInvoke rather than touching the control directly.

Each Window fires a predictable sequence of events: Loaded fires once the window's visual tree has been fully constructed and is ready for layout-dependent logic (measuring actual rendered sizes, for instance), Activated/Deactivated fire as the window gains or loses focus, and closing fires two events — Closing, which passes a CancelEventArgs so you can prompt 'save changes?' and abort the close by setting e.Cancel = true, followed by Closed, which fires once the window is actually gone and is the right place for final cleanup like unsubscribing event handlers or disposing resources.

How a WPF app decides to shut down is controlled by Application.ShutdownMode: the default, OnLastWindowClose, exits the app once every open window has closed; OnMainWindowClose exits as soon as the specific window marked MainWindow closes, even if other windows are still open; and OnExplicitShutdown disables automatic exit entirely, useful for tray-icon apps that should keep running with no visible window until code explicitly calls Application.Shutdown(). Whichever mode triggers it, the Exit event (or an OnExit override in App.xaml.cs) fires last, right before the process actually terminates, making it the correct place for final cleanup like flushing logs or releasing unmanaged resources.