~/home

Snipping Tool stuck on a busy cursor: a recycled PID

· windows, debugging

TL;DR: If Win+Shift+S shows only a busy cursor and SnippingTool.exe processes pile up, run taskkill /f /im SnippingTool.exe. The hang comes from the Windows App SDK AppInstance code treating a recycled PID as alive and leaving a mutex owned.

The screenshot shortcut stopped working. Each press showed a busy cursor for a moment and left one more windowless SnippingTool.exe behind. By the time I looked, 19 of them were sitting in Task Manager.

The fix

taskkill /f /im SnippingTool.exe

All of them have to go. If you kill them one by one, kill the waiting ones before the one holding the lock, or they wake up and each opens an overlay.

What was going on

Wait Chain Traversal showed every new instance waiting on a mutex owned by one old instance. The rest came from reading AppInstance.cpp in the open-source Windows App SDK:

  • Instances register their PIDs in a shared memory section. Nobody removes their own PID on exit; the next launch prunes the dead ones.
  • The only liveness check is whether OpenProcess(SYNCHRONIZE) succeeds. If Windows has already given that PID to some unrelated process, the dead entry counts as alive.
  • For each listed PID, the launcher creates a <app>_<pid>_Mutex with initial ownership, assuming the real owner created it first. For a recycled PID, the launcher itself becomes the owner and keeps it until it exits.
  • A cancelled snip (press Esc) leaves its process running. If that resident process is the one holding the leaked lock, every later launch waits forever.

In my case a Python process had picked up a PID that Snipping Tool had used an hour earlier. A few hours later one cancelled snip took the lock, and the shortcut died.

Useful tools for this kind of hang

  • Event 201 in Microsoft-Windows-AppModel-Runtime/Admin logs each launch. Compare with the timestamps in Pictures\Screenshots to see which launches produced a file.
  • cdb -pv -p <pid> -c "!handle 0 f Mutant; qd" from the Windows SDK lists named mutexes without symbols, and doesn't stop the process.