Not Responding is a message-loop state, not a fault: get the evidence before the reinstall

The useful part of the five-state taxonomy is what it implies about timing. Slow, not responding, blank, invisible, crash: four of those five leave a process that is still running and still open to inspection, and only the crash case has already exited by the time anyone gets to the keyboard ^{[4] [1]}. The evidence lives inside the hang, which is why the source asks you to record whether the window recovered on its own, rather than whether killing it worked ^[6].

Then do the arithmetic on the worked example. Normal at 10:04:12, freeze begins at 10:04:20, disk peaks for 15 seconds, window recovers at 10:04:42 ^[11]. That is a 22 second hang with 15 seconds of visible disk wait and 7 seconds that disk activity does not account for ^[2]. Seven unexplained seconds is a question worth writing into a ticket, and a screenshot of the greyed frame cannot pose it ^[11].

The author is careful in two places where internal support scripts usually are not. Task Manager's wait chain may show the UI process waiting on another process or thread, and the piece says outright that this does not prove root cause by itself; its value is that it stops random repairs ^[13]. The Application Hang entry gets the same treatment, with the recorded timestamp rather than the event ID doing the joining work between log line and observed freeze ^[17]. Anyone who has matched a hang to whatever warning happened to sit nearby in the log will recognise why that needed saying.

Two of the checks need no tooling at all. One is the file matrix: if a single document hangs and a small clean sample does not, the defect arrived with the data, and the installation is cleared before anyone touches it ^[21]. The other is walking Alt+Tab slowly through every window the program owns, because a sign-in prompt or an update prompt sitting at coordinates on a monitor that is no longer connected produces a window that looks frozen and is not ^[19]. The remedy there is to move the dialog onto the primary display and close the application normally so the new position is saved ^[20]. That is window-state housekeeping, and a coarse repair that resets position as a side effect ends the symptom while naming nothing.

One detail decides whether any of the readings mean anything: the process ID has to be the right one. Applications with helpers or a web-rendering runtime show child processes that have to be expanded first ^[8]. Get that wrong and the CPU and disk figures describe a shell that was never blocked, and high sustained CPU in a parsing or rendering child gets read as an idle parent ^[9]. The whole sequence fits in the few minutes between the freeze and the moment someone opens the installer, and it ends with one controlled change instead of several ^[22].