Jump to content
Sign in to follow this  
Ascend4nt

AutoIT functions misbehaving for Suspended apps

Recommended Posts

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 by ascendant

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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 by Authenticity

Share this post


Link to post
Share on other sites
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.


f_mrcleansmalm_77ce002.jpgAutoIt has helped make me wealthy

Share this post


Link to post
Share on other sites
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.

♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites
Valik

Larry, it's not used everywhere.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
Richard Robertson

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

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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 by Inverted

Share this post


Link to post
Share on other sites
Richard Robertson

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

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.