Windows Restart Manager: Updating In-Use Files Without Rebooting the Machine

Replacing an executable or DLL while another process has it open can fail, defer the change until reboot, or leave an application with a mixture of versions. Killing whatever appears in Task Manager is not a safe installer strategy: the file may belong to a service, several users may be logged in, and an application may need a chance to save state.

Windows Restart Manager provides an installer-facing coordination protocol. A primary installer starts a session, registers the files, processes, or services affected by its update, asks which applications use them, and can request an orderly shutdown and restart. The goal is to reduce system restarts, not to guarantee that every resource can be replaced live.

One primary installer owns the session

RmStartSession() creates a session and returns both a handle and a key. The primary installer keeps the handle. Secondary installers can join using the key when one product update contains multiple packages, allowing them to contribute resources without each trying to stop the same applications independently.

The key is coordination data and should be passed only to trusted child installers. It is not a general machine-wide discovery token. End the session with RmEndSession() on every exit path, including cancellation and rollback.

Only one component should decide when to call shutdown and restart. If each MSI, executable bootstrapper, and updater independently drives the lifecycle, users can see repeated prompts and applications can be restarted before all files are ready.

Register exact resources before asking who uses them

RmRegisterResources() accepts full file paths, unique process descriptors, and service names. Register the files that must be replaced, not an entire drive or broad directory guess. Microsoft notes that each registration call performs relatively expensive work, so group related resources rather than making one call per file in a tight loop.

Process identity includes both PID and process start time, which avoids confusing a terminated process with a later process that reused the number. Service resources use service names, not display labels. Normalize and validate every file path before registration so diagnostics match the object the installer will update.

Registration can evolve as secondary packages discover resources. Finish the complete set before presenting a final impact list to the user.

RmGetList is a changing snapshot

RmGetList() reports applications and services currently using registered resources and a reboot reason bitmask. The caller normally performs a sizing call, allocates the required array, and retries because the set can change between calls.

Treat the result as an explanation and planning snapshot, not a lock. Another process can open a DLL after enumeration. The eventual replacement operation still needs correct sharing flags and error handling. If the set changes, refresh the list or report the actual blocking resource instead of claiming the user closed the wrong application.

Display recognizable application names where available, but keep internal logs tied to resource path and unique process identity. Avoid exposing another user’s private window title or document name in a shared installer UI.

Shutdown asks applications to cooperate

RmShutdown() sends the coordinated shutdown request. Graphical applications receive normal close behavior, console applications and services follow their supported mechanisms, and Windows Explorer has specific Restart Manager handling. Applications may refuse, hang, or be marked critical.

The force-shutdown flag is not a harmless retry. It can discard unsaved work and should require an explicit product policy and user decision. An enterprise silent install still needs a documented data-loss contract, maintenance window, and rollback path.

Use the status callback to report progress and remain responsive. Cancellation must leave the update in a known state. Do not start replacing a subset of files while other registered users are still running unless the package was designed for that precise partial transition.

Applications opt into useful restart behavior

An application can call RegisterApplicationRestart() with command-line information that Windows may use after an update or other supported restart event. It should also participate in Windows shutdown guidance and save recoverable state promptly.

The restart command must not contain secrets or replay a destructive user action. On restart, distinguish recovery from a normal launch, validate any checkpoint, and let the user choose whether to reopen sensitive documents. Registration does not make arbitrary state serializable.

Services follow Service Control Manager behavior and their configured recovery design. The installer should not assume a service that stopped successfully can immediately serve requests after restart. Perform a health check and honor dependencies.

Restart follows replacement, not merely shutdown

The primary installer should call RmRestart() only after every coordinated package has finished the file operation and the product is internally consistent. Restart Manager restarts applications it can restart, but some processes will require manual launch or a reboot.

Order matters. If a secondary package fails, do not restart applications into a half-updated directory. Roll back to a complete old version or finish a tested repair path first. Persist enough installer state that a crash between shutdown and restart can be recovered on the next launch.

Applications may have exited independently, changed user session, or lost their restart eligibility. Treat restart results as best effort and communicate remaining actions accurately.

Some locks still require a reboot

Kernel components, boot-critical files, protected processes, session boundaries, permissions, and applications that cannot shut down can prevent live replacement. Restart Manager reports reboot reasons; it does not bypass Windows Resource Protection or loader constraints.

Never suppress a required reboot simply to improve an installer metric. A pending rename at restart and a clear user message are safer than running old code against new data. Conversely, do not demand a reboot before trying the supported coordination path.

Log the registered resource, discovered user type, shutdown result, replacement result, restart result, and reboot reason. That evidence distinguishes a product defect from an application that legitimately declined closure.

Test with real resource users

Build a matrix containing GUI apps with unsaved documents, console processes, Windows services, Explorer extensions, multiple user sessions, a process that hangs during shutdown, and a file opened after the first RmGetList(). Test update success, rollback, cancellation, installer crash, and machine reboot between phases.

Restart Manager is valuable because it gives every participant a defined role. The installer declares exactly what changes, Windows identifies current consumers, applications get a cooperative shutdown opportunity, and restart waits until replacement succeeds. That discipline reduces reboots without pretending that an in-use Windows system can always be updated atomically.

Related:

Sources: