Wardoff

Open-source Windows shutdown/reboot protection and idle-sleep prevention

Wardoff is a Windows-native Rust utility for people who want a visible, scriptable way to keep a machine in a protected Block state during gaming sessions, overnight jobs, remote work, or maintenance windows. The project is intentionally honest about what the current MVP does today and what still belongs to later releases.

Measured resource usage

Wardoff is lightweight while protecting a machine in the background. In our v0.2.0 benchmark on an Intel Core i7-6700HQ running Windows 11 IoT Enterprise LTSC, Block mode averaged approximately 14 MiB of resident memory and less than 0.01% total-machine CPU across three five-minute background runs. CPU is normalized across all eight logical processors.

Mean process resource usage	Allow	Block
Resident memory / Working Set (MiB)	12.57	13.95
Private committed memory (MiB)	1.96	3.25
CPU (% of total machine capacity)	0.0024%	0.0050%

The dated benchmark evidence includes the protocol, 2,700 raw samples, system information, tested binary hash, per-run statistics, limitations, and an integrity/reproduction checker. These are measurements on one machine, not universal guarantees. The UpdateOrchestrator Reboot task was absent, so its protection layer was inactive. Actual shutdown blocking, startup cost, heavy command workloads, battery use, and long-term memory growth were not tested.

Current MVP status

Wardoff currently ships a working tray/runtime app plus CLI with these MVP-level capabilities:

• Block/Allow runtime state with a red/green tray icon
• Layer 1 interactive shutdown and sign-out blocking through WM_QUERYENDSESSION, ShutdownBlockReasonCreate(), and SetProcessShutdownParameters()
• Layer 3 protection for the scheduled task Microsoft\Windows\UpdateOrchestrator\Reboot when that task exists
• Layer 4 best-effort remote shutdown abort polling with AbortSystemShutdownW(None)
• idle-sleep and automatic display-timeout prevention through Windows Power Requests, subject to Windows power policy
• structured rotating JSONL logging under %LOCALAPPDATA%\Wardoff\logs\
• single-instance coordination so later CLI calls can control the primary runtime
• Task Scheduler autostart management
• tray actions for Shutdown, Reboot, Sleep, Hibernate, and Quit

Documentation entrypoints

• Using Wardoff: continue with installation and usage below.
• Developing Wardoff: start with CONTRIBUTING.md, then the development guide for task-to-code routing and checks.
• Working as an agent: start with AGENTS.md; it uses the same workflow and documentation as human contributors.
• Finding a specific topic: use the documentation index.
• Choosing the next product change: read PLAN.md.

Not implemented yet

These are not part of the current documented MVP and should not be treated as shipped user-facing features:

• aggressive IFEO interception
• ETW-based local shutdown.exe interception as a documented feature
• Windows Event Log integration
• Windows toast notifications
• timers
• profiles
• settings UI
• packaged distribution via Winget, Scoop, Chocolatey, or a polished installer

For why IFEO stays out of the current MVP, see docs/IFEO_WARNING.md.

Honest limits

• Sleep protection means idle-sleep prevention. Explicit Sleep or Hibernate, power-button actions and lid closure can still suspend the PC. Wardoff does not block the screen saver or promise to prevent session locking.
• Windows power policy and request overrides can ignore keep-awake requests. On Modern Standby running on battery, system-required requests expire five minutes after the system sleep timeout expires. See the power behavior matrix and Microsoft sources.
• layers.sleep=true means Wardoff acquired its system/display request pair; it is not a guarantee that Windows will refuse every power transition.
• Wardoff does not promise to stop shutdown /t 0 /f. A forced zero-second local shutdown is outside what a normal user-space app can reliably block.
• Windows Update reboot-task protection requires administrator rights.
• Remote shutdown abort logic only helps when Windows still exposes a timeout window and the process has the rights required for AbortSystemShutdownW(None).
• Some CLI paths can run without elevation, but admin-only features will report that requirement instead of pretending they succeeded.
• On editions such as Windows LTSC where \Microsoft\Windows\UpdateOrchestrator\Reboot does not exist, Layer 3 is skipped automatically; that is normal, not a failure.

For the detailed per-layer behavior and the cautious Layer 2 local shutdown.exe wording, see docs/WINDOWS_SHUTDOWN_LAYERS.md.

What comes next

The repo is already in a conservative MVP state, so the next likely work is hardening and clarifying what already ships, not pretending a big new feature wave is done.

Today, a new agent should assume this order of priority:

1. improve confidence and docs around the implemented shutdown, update-reboot, remote-abort, sleep, tray, IPC, logging, and autostart behavior
2. keep build/run/read-order guidance easy for a first-time contributor or evaluator
3. treat larger feature ideas as later backlog unless PLAN.md explicitly moves them forward

For the current roadmap summary, read PLAN.md.

Installation

Wardoff is currently source-first.

Requirements

• Windows 10 or Windows 11
• Rust toolchain
• MSVC build tools for x86_64-pc-windows-msvc

Build from source

cargo build --release

The compiled binary is:

target\release\wardoff.exe

Signed binaries

The source code is free and open under the MIT license. Anyone can build Wardoff from source.

For users who want a verified binary without SmartScreen warnings, officially signed release binaries may be offered later as a convenience purchase. The signed binary would be functionally identical to what you build from source.

Pricing and download details are not active yet.

Usage

Quick start

wardoff
wardoff --version
wardoff --block --hide
wardoff --status
wardoff --autostart on
wardoff --log --tail 10
wardoff --allow

What the main commands do

wardoff
wardoff --block
wardoff --block --hide
wardoff --hide
wardoff --allow
wardoff --status
wardoff --log
wardoff --log --tail 10
wardoff --autostart on
wardoff --autostart off
wardoff --version

• wardoff starts a new primary runtime in Block mode with the tray visible when no primary instance is already running
• wardoff --block switches an existing runtime into Block mode, or starts a new headless Block-mode primary if none is running
• wardoff --block --hide is accepted and behaves like hidden Block-mode startup when it launches a new primary runtime
• wardoff --hide switches an existing runtime into Block mode, or starts a new Block-mode primary with the tray icon hidden
• wardoff --allow switches the running instance to Allow mode, or starts a visible Allow-mode runtime if needed
• wardoff --status prints compact JSON for scripts
• wardoff --log prints recent structured log entries
• wardoff --log --tail 10 prints the newest 10 structured log entries
• --tail accepts 0 through 100000 lines; larger values return a readable error without allocating the requested capacity
• wardoff --autostart on|off enables or disables the scheduled-task autostart entry
• wardoff --version prints the package version as wardoff <version>
• direct PowerShell invocations of wardoff --help, --version, --status, and --log --tail N now behave like normal console commands with real stdout, stderr, and exit codes

Read-only commands stay non-elevated:

• --help and --version short-circuit locally in clap
• --status reads status through the dedicated session-scoped WardoffStatus named pipe when a primary runtime is active
• --log and --log --tail N read the rotating JSONL log files directly
• those read-only commands stay attached to the calling shell so direct PowerShell CLI invocations can capture their output inline
• when no primary runtime owns the session mutex, --status returns {"state":"inactive"} without retrying the pipes
• when the mutex is occupied, the local implementation shares one absolute two-second connection-retry deadline between WardoffStatus and the legacy WardoffControl status fallback. It preserves the initial status retry grace, and an early status failure leaves the remaining connection budget for fallback. The target when both endpoints are unavailable is about two seconds plus scheduling overhead
• that connection budget does not limit response reads after a pipe connects, so it is not an end-to-end timeout for --status

State-changing/default behavior uses the normal runtime path:

• default wardoff startup bootstraps a new visible Block-mode primary runtime and may trigger Wardoff's built-in self-elevation path when admin-only protections are desired
• --block, --allow, --hide, and --autostart on|off are not read-only commands; they either start a runtime locally or talk to the primary runtime over the state-changing session-scoped WardoffControl named pipe
• when that primary runtime is already elevated, the same interactive Windows user can still send control-pipe commands from a normal non-elevated shell
• if the active primary runtime belongs to a different Windows user context, Wardoff reports that product mismatch clearly instead of surfacing a raw pipe access-denied error
• when a CLI launch would create a new long-lived primary runtime from an existing shell console, Wardoff relaunches that runtime in a detached background process so the shell prompt is not left hanging
• when the long-lived runtime starts from Explorer, autostart, or another launch path without an inherited shell console, Wardoff hides and frees any dedicated console window during startup

Example status output while Wardoff is active:

{"state":"block","layers":{"shutdown":true,"local_shutdown":false,"update":true,"remote":true,"sleep":true},"uptime_seconds":42,"blocked_count":3}

If no primary runtime is running:

{"state":"inactive"}

Exit codes

• wardoff --help exits 0
• wardoff --version exits 0
• wardoff --status exits 0 when Wardoff is active, exits 1 when no primary runtime is active, and exits 1 on errors
• wardoff --log and wardoff --log --tail N exit 0 on success and 1 on errors
• wardoff --block and wardoff --allow exit 0 on success, including when they start a runtime or switch the running runtime, and exit 1 when they fail
• wardoff --autostart on|off exits 0 on success and 1 on failure

Running as Administrator

Wardoff is explicit about elevation:

• the release manifest now stays at asInvoker, so explicit CLI invocations can start in a normal non-elevated console
• the release build now embeds that asInvoker manifest through the normal Windows resource path instead of ad-hoc linker flags, which makes the launch contract more predictable for shell invocations
• the release binary is now console-friendly in release builds, so direct PowerShell invocations of read-only commands stay in the calling console instead of behaving like a GUI-style launch
• if wardoff needs to bootstrap a new primary runtime with no explicit command, it still triggers Wardoff's built-in self-elevation path when administrator rights are needed for that default startup
• src/main.rs now keeps an explicit non-elevating read-only dispatch for --status and --log --tail N before any runtime bootstrap logic
• wardoff --status uses a dedicated read-only status pipe, and wardoff --log --tail N reads structured log files directly, so both commands stay non-elevated even when the primary runtime is already elevated
• state-changing secondary commands still use the session-scoped WardoffControl pipe, and Wardoff creates that pipe as local-only with explicit access for the current Windows user SID so same-user control still works across elevation boundaries
• a non-elevated shell can send --block and --allow to an elevated primary runtime when both belong to the same interactive Windows user; if Wardoff is running as a different user context, the CLI returns a clear product message instead of raw os error 5
• --help and --version still short-circuit inside clap and remain pure local console output
• if a new long-lived primary runtime is launched from an existing console, Wardoff detaches and relaunches that runtime so the console session can return immediately
• if a new long-lived primary runtime starts without an inherited shell console, Wardoff hides and frees the standalone console early so Explorer-style launches do not leave an empty console window behind
• Layer 3 UpdateOrchestrator protection requires elevation
• on editions such as LTSC where \Microsoft\Windows\UpdateOrchestrator\Reboot is missing, Layer 3 is skipped automatically and that is expected
• Layer 4 remote shutdown abort polling depends on the shutdown-abort privilege and is intended to run elevated
• --autostart on|off requires elevation because it changes a scheduled task
• if you run an explicit CLI command in a non-elevated console, Wardoff keeps working where it can and reports when an admin-only action is unavailable

Tray behavior

The current tray menu includes:

• Block
• Allow
• Start with Windows
• Shutdown
• Reboot
• Sleep
• Hibernate
• Quit

Red icon = Block mode. Green icon = Allow mode.

For manual verification of tray sync, Explorer restart recovery, secondary handoff windows, and admin-only Start with Windows behavior, use docs/MVP_VALIDATION_MATRIX.md.

Logging

Wardoff writes rotating structured JSONL logs to:

%LOCALAPPDATA%\Wardoff\logs\wardoff.jsonl

The current implementation keeps up to 3 log files and rotates when the active file grows past 5 MiB.

Comparison

Product	Source model	shutdown.exe story	Current reality
Wardoff	Open-source MIT	Honest MVP: interactive shutdown/sign-out blocking, UpdateOrchestrator protection, remote abort polling, but no documented ETW/IFEO local interception yet	Implemented MVP runtime on this branch
ShutdownBlocker	Closed freeware	Commonly associated with aggressive shutdown.exe interception approaches	Last known update March 2017
ShutdownGuard	Open-source MIT	Historical injection-based approach	Archived / unsupported
Don't Sleep	Closed freeware	Focused mainly on sleep/power-state prevention, not transparent shutdown control	Actively maintained
PreventTurnOff	Closed freeware	Similar positioning, simplified	Actively maintained

For the fuller product comparison, see docs/COMPARISON.md.

Contributing

Contributions are welcome. Start with CONTRIBUTING.md, then PLAN.md, and keep changes aligned with the current MVP boundaries.

Support the project

Wardoff is free and open source. If it saves you time or headaches, consider supporting the project:

• Sponsor on GitHub
• For community questions, issue routing, and current support scope, see SUPPORT.md

If officially signed release binaries become available later for SmartScreen-free deployment and verified authenticity, details will appear on the Releases page.

License

Wardoff is licensed under the MIT License.