_NET_WM_PING
De manier waarop de window manager ontdekt of een applicatie is vastgelopen, plus de PID-eigenschap die het mogelijk maakt het juiste proces te beëindigen.
De X-server merkt nooit dat een programma niet meer reageert: de verbinding is open, het venster staat getekend en de klikken wachten beleefd in de buffer van de server. EWMH gaf de window manager een test. Een programma dat _NET_WM_PING in WM_PROTOCOLS heeft opgenomen, krijgt van tijd tot tijd en altijd als de gebruiker op de sluitknop drukt een ClientMessage met een tijdstempel en zijn eigen venster-ID, die het ongewijzigd naar het rootvenster moet terugsturen. Het antwoord komt uit de eventlus van het programma, dus een programma dat vastzit in een berekening of een blokkerende aanroep antwoordt niet, en na enkele seconden kan de window manager concluderen dat het is vastgelopen. Daar komt het dialoogvenster „applicatie reageert niet” van Mutter en KWin vandaan. GTK en Qt beantwoorden de ping binnen de toolkit, dus een applicatieprogrammeur ziet hem nooit.
Een X-programma doden is lastiger dan het klinkt. XKillClient sluit alleen de verbinding, en een proces dat daar niet naar luistert, draait vrolijk door zonder venster. Daarom zette EWMH ook _NET_WM_PID op het venster, zodat de window manager na een gemist antwoord SIGKILL naar het juiste proces kan sturen — nadat hij WM_CLIENT_MACHINE met zijn eigen hostnaam heeft vergeleken, want een PID van een andere machine is betekenisloos. Containers en Flatpak, met hun eigen PID-namespaces, maakten de truc weer onbetrouwbaar, een les die Wayland ter harte nam: daar beantwoordt de client pings binnen het protocol zelf en kent de compositor het proces via de socket.