3

What does this message means, is there an API to « respond » to Microsoft Windows status queries ?

I'm looking for a technical answer. Thanks :)

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Nope
  • 897
  • 1
  • 8
  • 15
  • 2
    See https://msdn.microsoft.com/en-us/library/windows/desktop/ms644927(v=vs.85).aspx - "If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding." – 404 Jun 02 '15 at 09:55
  • http://stackoverflow.com/questions/6997310/busy-application-leads-to-false-not-responding-state-on-windows-7-wm-update, http://stackoverflow.com/questions/1691251/what-makes-a-process-appear-as-not-responding-in-windows, http://stackoverflow.com/questions/402832/avoiding-not-responding-label-in-windows-while-processing-lots-of-data-in-on, try searching. – CodeCaster Jun 02 '15 at 10:08

2 Answers2

7

What this means is that the program is failing to service its message queue. From the documentation:

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. When in the debugger mode, the system does not generate a ghost window.

Typically this means that the main thread of the program is busy and is not calling GetMessage frequently enough. Long running tasks should be performed on a thread other than the main UI thread.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 1
    Frequently enough = 5s. IsHungAppWindow ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms633526%28v=vs.85%29.aspx ) says : 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. Thanks. – Nope Jun 02 '15 at 10:46
  • 1
    `This allows the user to move it, resize it, or even close the application.` I beg to differ. – arkon Sep 11 '16 at 03:39
  • @b1nary if so you should submit a bug report to Microsoft then – David Heffernan Sep 11 '16 at 06:44
3

Windows applications interact with the operating system by receiving window messages. These messages are processed by the application in its main thread in a loop.

If an application fails to process its messages in time (several seconds are the margin there), its message queue fills up and Windows marks this application as "not responding", rendering its main window white-ish and the such.

Such behaviour is mostly caused by doing a lengthy operation on the same thread that processes the window messages. This thread is often referred to as the "main UI thread". If you do not do any explicit multi threading, it may well be the only thread of your application.

Spooky
  • 2,966
  • 8
  • 27
  • 41
Peter Brennan
  • 1,366
  • 12
  • 28
  • This is not accurate. In this case the system observes that the messages that it sends are not being dealt with in time. These messages come from a different process and are not delivered by direct calls to the window procedure. Because that's not possible from a different process. Cross process (and indeed cross thread) messages are dispatched when the target thread calls a message dispatch function such as `GetMessage`, `PeekMessage`, `SendMessage` etc. – David Heffernan Jun 02 '15 at 10:16
  • 1
    You are right. Got things mixed up. Corrected my answer. – Peter Brennan Jun 02 '15 at 10:26