AutoIT functions misbehaving for Suspended apps

[Ascend4nt]

Hi, I've been recently messing around with a program to close crashed or hung applications, and noticed that calling the below functions causes the script to come to a complete halt (its a good idea to get the $hWnd handle beforehand):

WinGetTitle()

WinSetState()

I'm wondering if this should be reported as a bug or not? To see for yourself - try running Advanced Process Termination and clicking one of the 'Suspend' options for an application (say, notepad, for example).

Now if you run either of the above functions on the window (I did @SW_MINIMIZE for the state), the script will hang. Once you 'Resume' the process, however, the script starts running again.

The workaround, at least for WinGetTitle(), is to do a 'SendMessageTimeout' call. I'm not sure whether there's a timeout option in the API calls for setting a Window state?

Two additional things I've noticed on suspended apps is that:

WinGetHandle("[ACTIVE]") returns 0 for suspended apps, and doesn' set @error

WinGetProcess ("[ACTIVE]") returns incorrect #'s for suspended apps (instead of say, -1)

Should any\all of these be reported as bugs?

Thanks

*edit: ooh, just found this additional alternative to getting the Window Title: InternalGetWindowText

Edited June 22, 2009 by ascendant

[Valik]

There are no bugs here. I'm also not certain we should do anything about this. Thread/process suspension is not a standard feature of the Windows API. It requires either using a function clearly labeled as "for debugger use" or calling an undocumented function. "Fixing" the issue requires changing a whole lot of code to cover a corner case that thus far has never been reported in six years.

[Ascend4nt]

Do you know of a way to test these functions on crashed applications (that still linger)? I'd be interested if the same behavior results. I'm still trying to find a way to get an app to crash in that way so I can test such a thing.

[Valik]

What do you mean by linger? When an application crashes it is closed. If not, then something has screwed up in the kernel and the entire OS is likely now unstable.

[Ascend4nt]

Hmm.. well I'm not exactly sure what the application is doing when it crashes, its just giving the (not responding) message in Task Manager, and for games that crash - the whole screen stays up (which was the point of my "Full-Screen Crash Recovery" program). Unfortunately, I've not been able to reproduce the problems lately, and I don't recall exactly which apps/games were doing it - but I do know of people it still happens to (and you know how buggy games can be)

[Valik]

Are you confusing deadlocking with crashing? For example a problem I have with games is when I forget to allow them in my firewall. Then when the game is blocked and the firewall is prompting me to allow/deny access, I'm stuck if the game won't let me alt+tab out. But in a situation like that, nothing has crashed, things have just deadlocked.

[Ascend4nt]

Nope, though I've seen that situation happen enough. I mean crash as in it just stopped working period. Usually the screen will lock on one frame, sometimes the sound will keep repeating one sequence over and over, and nothing you do can get you out of it. Annoys the heck out of me, especially when sometimes the Windows key will allow you to *briefly* see the taskbar sometimes, or when Ctrl-Alt-Delete will bring up the application, and *sometimes* show you parts of it as the mouse crosses over it.

Then there are regular programs that crash, but usually let you maneuver around windows. Sometimes it will seem as though they have completely closed - but you'll still see the process in Task Manager.

There's really such a range of program crashes, I'm surprised you wouldn't have encountered at least some of these?

[Valik]

Meh. Yes, of course I've had those things happen. But you're not being very clear. When you say "crash" I interpret to mean Windows has shown you an error dialog.

[Ascend4nt]

Well yah, I guess there's a few definitions of 'crash' when it comes to computers. Even the dictionaries have the term listed broadly in describing the matter (in respect to computers/programs). 'Lockup' is probably a better word.

Anyway, that's what I'm looking to reproduce, so I can test those AutoIT functions. Just need access to a PC or game/program that has that happen consistently..

[Authenticity]

Just a side note. I may be wrong because I'm not sure how AutoIt is implementing the get window caption code but I'd assume, either explicitly or implicitly, it's calling WM_TEXT. If it's by SendMessage, you're going to be blocked because of asynchronous design of the message queue. If it's, PostMessage or SendMessageTimeout you're good to go.

Edited June 23, 2009 by Authenticity

[LarryDalooza]

Just a side note. I may be wrong because I'm not sure how AutoIt is implementing the get window caption code but I'd assume, either explicitly or implicitly, it's calling WM_TEXT. If it's by SendMessage, you're going to be blocked because of asynchronous design of the message queue. If it's, PostMessage or SendMessageTimeout you're good to go.

I haven't been in the code in some time, but it is my understanding that we use SendMessageTimeout.

Lar.

[trancexx]

I haven't been in the code in some time, but it is my understanding that we use SendMessageTimeout.

Lar.

I would say SendMessageW two times. First time WM_GETTEXTLENGTH to get length and then WM_GETTEXT to get the caption.

[Valik]

Larry, it's not used everywhere.

[Jon]

There are places where windows are checked for a hung state using SendMessageTimeout before we try and work with them. But yeah, don't think it's everywhere.

[Ascend4nt]

Update:

I was able to test these functions on actual crashed applications (woo!), and it turns out that every function that I've had problems with on Suspended apps returns okay - EXCEPT WinGetProcess()

For some reason, WinGetProcess() on crashed windows, using either the name or the $hWnd, will return explorer.exe's Process ID. Wth? Can anyone explain that?

I'm going to have to try to find an alternate means to figure out the correct Process ID I suppose..

[Richard Robertson]

The hanging window may not be able to respond so the shell is kicking in. That's my guess.

[Ascend4nt]

Hmm, I wouldn't know. I tried calling the 'GetWindowThreadProcessId' API function myself, and it returned the same thing. I was however able to get a true return on 'IsHungAppWindow', so at least I know the application has crashed or locked up. But how the heck do I find out the process ID based on just the window... there must be another way..

[Inverted]

But how the heck do I find out the process ID based on just the window... there must be another way..

I haven't been following this thread really, but in asm I do GetWindowThreadProcessId (after FindWindow)

EDIT: oh, ok, disregard this then, I was blind for a minute

Edited July 7, 2009 by Inverted

[Richard Robertson]

You didn't even read the post you replied to. He just said he called that function.

[Ascend4nt]

Hmm, this is interesting. Turns out explorer.exe had crashed too. So, I terminated that, did WinGetProcess() again, and this time it returned the correct process.

Now, the functions WinGetTitle() and WinSetState() both freeze up AutoIT for the crashed apps. I'm able to use other functions, but those ones were working *prior* to killing explorer.exe. Really odd.

Being as how I'm trying to make the program of mine 'Full-Screen Crash Recovery' work correctly, I'm now a little concerned about how I should handle weird situations like this. I normally discard results that match the process ID of explorer.exe to prevent closing that down by accident, but what I need to figure out is if there's a way to distinguish between legitimate explorer windows or not..