IsHungAppWindow docs?

[Neil Gilmore]

Hello,

I've been taked with overhauling some code that is supposed to deal with
restarting crashed/hung processes (and incidentally, starting
processes). The old implementation uses shared memory and timers in
every client application, and it just doesn't work well (some weirdness
with how handles are dealt with), as well as the fact that we can't
monitor applications that we didn't write. Yes, our apps aren't supposed
to crash or hang, this is another layer of protection.

So I did a dumpbin on taskmgr.exe to see what it called to try and get
some ideas. The function IsHungAppWindow() would seem to be a pretty
good choice for the purpose, but our MSDN stuff from October doesn't
seem to have anything on that function. Also, I couldn't find anything
on the functions in ntdll.dll (I'm probably supposed to use some other
mechanism, like the registry perf info, yecch).

So could anyone point me to information on these?

Thanks

Neil Gilmore
ra...@raito.com

[William DePalo [MVP]]

Neil Gilmore wrote in message <36939668...@raito.com>...

>So I did a dumpbin on taskmgr.exe to see what it called to try and get
>some ideas. The function IsHungAppWindow() would seem to be a pretty
>good choice for the purpose, but our MSDN stuff from October doesn't
>seem to have anything on that function.

The popular wisdom is that the task manager sends a message to a window and
waits for timeout to detect hung applications. I haven't disassembled the
code and have no access to the source so I can't say for sure. :-) Check the
docs for SendMessageTimeout(...SMTO_ABORTIFHUNG). If I recall correctly the
message sent is WM_NULL and the timeout is 5000 ms.

Regards,
Will

[Neil Gilmore]

William DePalo [MVP] wrote in message ...

Thanks, Will.

This seems to be really close to what I need to do (I'll have to do some
experimenting). BTW, that IsHungAppWindow() is linked in from user32, so I
figured that there would be docs out there somewhere.

Neil Gilmore
ra...@raito.com

[Raymond Chen]

IsHungAppWindow is a private function used by User32 to determine
things like whether SMTO_ABORTIFHUNG should abort or not, or
whether it should give up on an application and force-paint its
background because the app isn't painting. It is not for general
use. (For example, it isn't supported on all Windows platforms.)

If you want to see if an app is hung, use SendMessageTimeout with
SMTO_ABORTIFHUNG and the WM_NULL message.

--
(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.)

[Neil Gilmore]

Yeah, that's what I finally figured out, after a couple of people mentioned
SendMessageTimeout (which I hadn't used before, and will work pretty well
for my problem). Next problem is figuring out what is an 'application'
(again, like Task Manager). I can EnumWindows, and GetModuleFileName to
figure out what I'm interested in. I can even use the instance handles to
deal with 2 of the same applications (which the current program doesn't deal
with well). But EnumWindows seems to return a lot of windows I don't care
about, and figuring out how Task Manager decides what goes into the
Applications tab would probably cut down the time to do the processing.

See, if my monitor application doesn't start up an application, but it is
one that I care about, then I'm supposed to monitor it if it is started
manually (Don't ask me why, I don't write the specs).

Anyway, thanks to all of you who helped.

Raymond Chen wrote in message <369740ce.2413965578@msnews-gw>...

Neil Gilmore
ra...@raito.com

[William DePalo [MVP]]

Neil Gilmore wrote in message <775qjh$4p8$1...@grandprime.binc.net>...

>But EnumWindows seems to return a lot of windows I don't care
>about, and figuring out how Task Manager decides what goes into the
>Applications tab would probably cut down the time to do the processing.

What follows was taken from an old post of David Lowndes:

The requirements of what types of window are displayed on the taskbar
was mentioned by Jeffrey Richter in MSJ Nov 1997:

"The rules the taskbar uses to decide whether a button should be shown
for a window are really quite simple, but are not well documented.
When you create a window, the taskbar examines the window’s extended
style to see if either the WS_EX_APPWINDOW (defined as 0x00040000) or
WS_EX_TOOLWINDOW (defined as 0x00000080) style is turned on. If
WS_EX_APPWINDOW is turned on, the taskbar shows a button for the
window, and if WS_EX_ TOOLWINDOW is turned on, the taskbar does not
show a button for the window. You should never create a window that
has both of these extended styles.

You can create a window that doesn’t have either of these styles. If a
window has neither style, the taskbar decides to create a button if
the window is unowned and does not create a button if the window is
owned.

One final note: before making any of the above tests, the taskbar
first checks to see if a window has the standard WS_VISIBLE window
style turned on. If this style bit is off, the window is hidden; the
taskbar never shows a button for a hidden window. Only if the
WS_VISIBLE style bit is on will the taskbar check the WS_EX_APPWINDOW,
WS_ EX_TOOLWINDOW, and window ownership information.
"

Regards,
Will

[Neil Gilmore]

That's great information, which I will have to file in the back of my head.
Unfortunately, it won't do me any good on this particular project, after
more digging for what is actually required. It turns out that about half the
apps that I have to monitor wouldn't be detected by this method, if this is
what Task Manager does. This is because thay stick their icons in the system
tray. Those apps don't show as apps to Task Manager until they are made
visible. So I'll have to parse through everything. But I can do it.

Thanks to everyone for the information.

Neil Gilmore
ra...@raito.com

William DePalo [MVP] wrote in message ...