174

How does Windows know if a program is not responding? Does it constantly keep polling all running applications?

150

An application gets the events from a queue provided by Windows.

If the application doesn't poll the eventqueue for a while (5 seconds), for example when doing a long calculation, then Windows assumes that the application is hung and alerts the user.

To avoid that applications should push expensive calculations to worker threads or split up processing and make sure the queue gets polled regularly.

  • 27
    ↑ This. Nothing to do with scheduling or such as suggested in the accepted answer, only whether you regularly call GetMessage (or the like) and DispatchMessage. – Damon Aug 24 '15 at 14:40
  • 1
    The accepted answer, in referring to IsHungAppWindow correctly notes that a program in the startup phase doesn't have to call GetMessage. – MSalters Aug 25 '15 at 9:56
  • @MSalters With startup being defined as the time before the first GetMessage? That feature allows simple command line apps to work without being considered hung as they don't need to poll the queue. – ratchet freak Aug 25 '15 at 11:54
  • 4
    @ratchetfreak: Presumably before the first CreateWindow call. Command line apps are different beasts altogether; they're running inside ConHost.EXE and it interacts with the Windows GUI susbystem for them. – MSalters Aug 25 '15 at 12:27
  • 1
    also, it seems to me that in Windows 7 (and possibly earlier) that windows will notice this much sooner if you try and fail to manipulate the window in some way. like if a program doesn't process a maximize or move message, windows 7 will jump right to not responding after about 1 or 2 seconds.. – Dave Cousineau Aug 26 '15 at 22:33
78

How does Windows know if a program is not responding?

Without the source code to Windows we cannot be sure what it is doing internally.

There is an SDK Windows function IsHungAppWindow that can be used.

An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not called PeekMessage within the internal timeout period of 5 seconds.

Source IsHungAppWindow function

If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding. In this case, the system hides the window and replaces it with a ghost window that has the same Z order, location, size, and visual attributes. This allows the user to move it, resize it, or even close the application. However, these are the only actions available because the application is actually not responding.

Source About Messages and Message Queues


Does it constantly keep polling all running applications?

No. Applications are not polled but given processor time.

Windows has a scheduling system that gives processor time to application threads.

The scheduling algorithm is complex, and is fully described in Windows Internals, Part 1 (6th Edition) (Developer Reference).

  • 2
    The hang state is not based on CPU. Most programs are "hung" in that sense for 99.999% of the time and do nothing. – usr Aug 24 '15 at 10:52
  • 2
    @usr Where did I say that "hung" depends on CPU? – DavidPostill Aug 24 '15 at 10:54
  • 2
    @usr The first half of the answer is answering "Does it constantly keep polling all running applications?". The second half is answering "How does Windows know if a program is not responding?. The OP asked two questions in one ;) – DavidPostill Aug 24 '15 at 10:59
  • 9
    It's not really polling, though, is it? I assume the internals are more like a wait handle on the window is signalled when you call PeekMessage. So when Windows sends a message to the application, and doesn't get signalled within five seconds, it marks the application as not responding. And in fact, on more recent Windows, the window is only marked "not responding" if it failed to respond to user input in time - until I try to click or press a key or something, the application can easily stay "hung" for minutes without "appearing" non-responsive. – Luaan Aug 24 '15 at 11:56
  • 2
    You can delete everything above "About Messages and Message Queues" as it doesn't help the answer. Windows knows an app has stopped responding because it stops pumping messages. The app could be running though as its doing something intensive instead of pumping messages(but thats a poorly designed program). – Andy Aug 25 '15 at 22:01
32

Actually, Windows doesn't always know that an application is not responding. The application has to be an interactive application with a window, and the window must be receiving messages that the application fails to process, before Windows concludes that the application is not responding.

For instance, Windows has no way of knowing if a number-crunching application with no user interface that is run from the command line is doing its thing, or perhaps stuck in an infinite loop.

Interactive graphical applications in Windows receive events by continuously polling a message queue. Windows populates this message queue with keyboard, mouse, timer, etc. events. If an application fails to poll the message queue for some time (5 seconds is the timeout mentioned in the IsHungAppWindow() function documentation), Windows considers the application "hung", which it may indicate by changing the window title (adding the text "(Not Responding)" or equivalent text in localized versions) and greying out the window contents if the user tries to interact with the window.

Applications can hang in ways that Windows does not recognize. For instance, an application may continue polling for messages in its message queue without properly acting on them, so for all practical intents and purposes it would appear "hung" without Windows recognizing that it is non-responsive.

  • 8
    Not responding, by definition, means not processing window messages, so it doesn't apply to services or console apps, and so i'd say Windows does always know if an app is not responding. You're confusing dead locks and not responding. – Andy Aug 25 '15 at 22:05
  • Of course it can know if a program isn't responding. "Not responding" is not the same as "stuck in an infinite loop" – BlueRaja - Danny Pflughoeft Aug 25 '15 at 23:50
  • 1
    Actually, an application can retrieve messages via GetMessage() and fail to process them, and it would not be recognized as "not responding" by Windows despite the fact that it would certainly appear non-responsive to its user. The term "not responding" is also often used to describe network, service, interactive command line, etc. applications; AFAIK there is no formal definition that limits the phrase to windowed applications. Both a deadlock or an infinite loop (or any other programming error) can cause an application to become non-responsive, but no, I did not confuse cause and effect. – Viktor Toth Aug 26 '15 at 3:29
10

Windows is an operating system, it's supervising all running programs.

Windows communicates with window-based applications using events. Every program has a thread that constantly listens for incoming events and processes them. For example when you click a button or a notification area icon, Windows generates an event and feeds it into appropriate process. The process can then decide how to handle it.

All interactions with programs are event-based in Windows, so when program doesn't process incoming events for too long, it means it doesn't respond. As @DavidPostill has found and noted in his answer, the timeout is 5 seconds. PeekMessage is the function that gets an event from event queue.

0

The answer to your question is yes/NO.

While the Windows OS can and does poll applications with events in the Windows Messaging Queue, programs are under absolutely zero obligation to link to the WinAPI or handle/answer the Windows Queue. Even answering a message in the Queue does not tell Windows whether the program has "locked up" or not. It's an indicator, but that's all it is. The real answer is quite a bit more complicated.

The real Answer

People are hedging around the actual answer here. Determining whether a program is "not responding" is a variant of the "halting problem", which is formally undecidable in computer science. The short explanation is that the processor cannot act as a third party observing itself to determine whether a subroutine is stuck in an infinite loop, doing nothing vs incrementing a counter which will terminate at some fixed, normal number. Both of these can be considered to be tightly closed loops. One halts, the other will never terminate. Even you, as a person, don't know whether a program is actually responding or not, especially if it is in a tightly closed loop -- you only know if think it should (respond).

From Windows' perspective, both of these loops are "not responding". That's why windows gives you the choice to wait or terminate, because it cannot tell.

So the corollary is "why does windows know that a process is responding?" The answer is rather clever. When a process is compiled in a multi-threaded & multi-process OS, sometimes even in tightly closed loops, the compiler may add in a yield() command, which provides a convenient notification to the processor that it can switch to other running processes. It "gives up" the processor and a "context switch" (as it is called) happens that allows the OS (Windows included) to answer other events in the stack, some of which include tracking that the process has responded.

**This does not mean that a responding process will terminate. ** A process inside an infinite loop can yield the processor, allowing Windows to process other events.

In some windows programs, the program will handle Windows OS signals, which can tell the OS it is "responding", but no program is under any obligation to do so. You can write quite simple CPU hogging, non-terminating programs even inside higher level languages on Windows such as perl, php, python, and Windows may not detect that it is not terminating and not responding. At that point, Windows depends upon heuristics -- CPU load, memory, how many interrupts the processor handled while the program was running to "guess". Again, at that point, Windows has to ask you to terminate, because it really does not know if it should.

See also Viktor's (correct) answer. Ignore the comments about whether "not responding" is not the same as an infinite loop. There are all kinds of messages, interrupts, loops that an application may or may not handle without informing the Windows message queue. Handling the message queue is only one of many kinds of events that the OS keeps counters on to try to guess whether a process is hung.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.