Does Vista treat Not Responding windows special?

[Kevin]

Hello,

I am working on a problem where an application becomes "Not Responding",
because it does not process window messages in a message loop properly.

Does Windows Vista treat "Not Responding" windows specially? It would
explain why screen updates do not occur, whereas they do occur on XP / 2000
/ 9x.

I thought I read something to that effect, but can not find the reference.

Thanks.

 

[Skywing [MVP]]

The shell will hide the `broken' window and substitute a `ghost' window with
similar characteristics that is moveable and responds to messages. If the
program wakes back up, the `ghost' window is removed and the real window is
moved/sized according to what the user did with the `ghost' window.

This is similar to Windows XP and Windows Server 2003.

If you have attached to a process with a debugger, the behavior of creating
`ghost' windows is suppressed for the process being debugged so long as the
debugger remains attached.

 

[Kevin]

Thank you for the information! The problem report indicated Vista-only, but
that must have been an oversight. .

I will respond to the report by saying that the observed behavior is as
expected, that because the app is not processing messages, the window is not
updated because it has been replaced by a "ghost" window.

And thanks for the information pertaining to the debugger. Naturally, I was
running the program under a debugger, and so it is good to know when doing
so alters behavior!!

Thanks again!!

 

[helpdesk]

The shell will hide the `broken' window and substitute a `ghost' window with
similar characteristics that is moveable and responds to messages. If the
program wakes back up, the `ghost' window is removed and the real window is
moved/sized according to what the user did with the `ghost' window.

This is similar to Windows XP and Windows Server 2003.

If you have attached to a process with a debugger, the behavior of creating
`ghost' windows is suppressed for the process being debugged so long as the
debugger remains attached.

Hello,

I have the same problem but my application sends almost every second
some
new message to the screen which I now cannot see anymore ( it shows
relevant information about the process ).
If the process ask for user-intervention then the screen is active
again.
It is very unpleasant because the messages which are lost are
important.
May be it was already in XP but it does not show up there

Herman

 

[Kevin]

I have the same problem but my application sends almost every second
some
new message to the screen which I now cannot see anymore ( it shows
relevant information about the process ).

This is because the application is not running the "while (GetMessage()) /
DispatchMessage()" loop. Pre-XP, application windows that did not run the
standard message loop were ill-behaved, but the screen would still be
updated. From XP and beyond, these ill-behaved apps get their windows
disconnected from the screen.

If the process ask for user-intervention then the screen is active
again.

This is because the user-intervention probably displays a DialogBox(), which
does run the "while (GetMessage()) / DispatchMessage()" loop. The
previously-sent messages get processed, so the window is no longer "Not
Responding", and screen updates can occur.

It is very unpleasant because the messages which are lost are
important.

You have to run the standard message loop, and split the processing into
"chunks", and process a "chunk" while handling a window message.

Or, you run the standard message loop, but start a new thread to do the
processing.

Or, you convert the program to be a console application.

May be it was already in XP but it does not show up there

I found that the MSDN for GetMessage documents this "ghost" behavior for XP:

"Windows XP: If a top-level window stops responding to messages for more
than several seconds, the system considers the window to be hung 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 hung. When in the debugger mode, the system does
not generate a ghost window."

Note: the statement "the application is actually hung" is somewhat
misleading. The application is actually still running. But, because it is
ill-behaved, the operating system classifies it as hung.