performance

HungAppTimeout and WaitToKillAppTimeout: shutdown speed, honestly

Two values decide how long Windows waits for apps at logoff. Shorter is snappier — until you lose unsaved work. The measured trade-off with documented defaults.

ProofTune Project··5 min read
Performance illustration Performance

The values under Control Panel\Desktop

HungAppTimeout (ms)
how long Windows treats a busy app as “busy” before calling it hung — stock 5000
WaitToKillAppTimeout (ms)
how long logoff waits for a hung app to release — stock 5000

What changing them feels like

Halving both (a common tweak) shows up at exactly one moment: sign-out/restart with an application stuck in a dialog — the wait floor determines how annoying “close programs first” is. The risk profile is the mirror: an editor with unsaved changes that was going to beep at you in 4 s gets murdered a second earlier.

What it won't touch

  • Perceived speed of a desktop doing nothing special — the values sleep until sign-out.
  • Slow app launches; nothing about them gates open-time.
  • Structured-crash dialogs (WER dialogs have their own timers).

The tuning stance: set both to a deliberately documented lower value, log the before-image, and — most of all — know that two-second gain only ever matters when something else has already gone wrong.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.