This is super speculative and I'm only writing this because no one's mentioned message loops.

A common reason for loss of responsiveness in a Windows program is it stopping processing its message queue, which it does by calling GetMessage/DispatchMessage in a tight loop. DispatchMessage returns after WinProc, a programmer-provided callback function associated with a window's "window class", has run. Trying to do slow/potentially slow things (like looking for a file on a network share that is down) directly in the WinProc would cause the program to appear to freeze. It must be added that in systems that are not very robust to begin with, freezing is almost always due to something outside the program's control. A program just going into an infinite loop would be a serious bug that would be caught early on.

I can imagine that the way Crash Guard would remedy at least this kind of freezing was by restarting the message loop, by making the program jump into its main window's WinProc, perhaps with uMsg set to a no-op like WM_NULL. Callbacks like WinProc are also externally visible entry points. Jumping into WinProc (perhaps unwinding the stack while one's at it, too) seems like a plausible mechanism to try and put the program back on track (how ever random of a track in terms of the program's dynamic history.)

This is super speculative and I'm only writing this because no one's mentioned message loops.

A common reason for loss of responsiveness in a Windows program is it stopping processing its message queue, which it does by calling GetMessage/DispatchMessage in a tight loop. DispatchMessage returns after WinProc, a programmer-provided callback function associated with a window's "window class", has run. Trying to do slow/potentially slow things (like looking for a file on a network share that is down) directly in the WinProc would cause the program to appear to freeze. It must be added that in systems that are not very robust to begin with, freezing is almost always due to something outside the program's control. A program just going into an infinite loop would be a serious bug that would be caught early on.

I can imagine that the way Crash Guard would remedy at least this kind of freezing was by restarting the message loop, by making the program jump into its main window's WinProc, perhaps with uMsg set to a no-op like WM_NULL. Callbacks like WinProc are also externally visible entry points. Jumping into WinProc (perhaps unwinding the stack while one's at it, too) seems like a plausible mechanism to try and put the program back on track (no matter how random of a track in terms of the program's dynamic history.)

This is super speculative and I'm only writing this because no one's mentioned message loops.

A common reason for loss of responsiveness in a Windows program is it stopping processing its message queue, which it does by calling GetMessage/DispatchMessage in a tight loop. DispatchMessage returns after WinProc, a programmer-provided callback function associated with a window's "window class", has run. Trying to do slow/potentially slow things (like looking for a file on a network share that is down) directly in the WinProc would cause the program to appear to freeze. It must be added that in systems that are not very robust to begin with, freezing is almost always due to something outside the program's control. A program just going into an infinite loop would be a serious bug that would be caught early on.

I can imagine that the way Crash Guard would remedy at least this kind of freezing was by restarting the message loop, by making the program jump into its main window's WinProc, perhaps with uMsg set to a no-op like WM_NULL. Callbacks like WinProc are also externally visible entry points. Jumping into WinProc (perhaps unwinding the stack while one's at it, too) seems like a plausible mechanism to try and put the program back on track (however random of a track in terms of the program's dynamic history.)

This is super speculative and I'm only writing this because no one's mentioned message loops.

A common reason for loss of responsiveness in a Windows program is it stopping processing its message queue, which it does by calling GetMessage/DispatchMessage in a tight loop. DispatchMessage returns after WinProc, a programmer-provided callback function associated with a window's "window class", has run. Trying to do slow/potentially slow things (like looking for a file on a network share that is down) directly in the WinProc would cause the program to appear to freeze. It must be added that in systems that are not very robust to begin with, freezing is almost always due to something outside the program's control. A program just going into an infinite loop would be a serious bug that would be caught early on.

I can imagine that the way Crash Guard would remedy at least this kind of freezing was by restarting the message loop, by making the program jump into its main window's WinProc, perhaps with uMsg set to a no-op like WM_NULL. Callbacks like WinProc are also externally visible entry points. Jumping into WinProc (perhaps unwinding the stack while one's at it, too) seems like a plausible mechanism to try and put the program back on track (how ever random of a track in terms of the program's dynamic history.)