Full-Screen Crash Recovery 1.0

[montymintypie]

I worked out a way to test it. Press twice, it minimises Firefox. Press again, it terminates. Works beautifully! It's good to know I can recover from a frozen game.

Thanks! This is going in my startup items.

Found window matching criteria, Maximized status=True, Alternative Full-Screen test result=False...
Checking if window 'Full-Screen Crash Recovery - AutoIt Forums - Page 2 - Mozilla Firefox' (process ID #4012) is 'hung'...
Window 'Full-Screen Crash Recovery - AutoIt Forums - Page 2 - Mozilla Firefox' not reporting 'hung' status
Found window matching criteria, Maximized status=True, Alternative Full-Screen test result=False...
Checking if window 'Full-Screen Crash Recovery - AutoIt Forums - Page 2 - Mozilla Firefox' (process ID #4012) is 'hung'...
SendMessageTimeoutW (WM_GETTEXT msg) return succeeded, text return = 'Full-Screen Crash Recovery - AutoIt Forums - Page 2 - Mozilla Firefox'
2nd attempted Kill command received. Sent 'Minimize-window' command to window..
Found window matching criteria, Maximized status=True, Alternative Full-Screen test result=False...
Checking if window 'Full-Screen Crash Recovery - AutoIt Forums - Page 2 - Mozilla Firefox' (process ID #4012) is 'hung'...
Process ID #4012 not reporting hung status, but attempted kill count=3, so terminating..
Process terminated (or attempted to be).
---------------------------------------------------------------

[Ascend4nt]

montymintypie, thanks for the info/update.

I actually have a rewrite of the whole program (well, at least parts of it) due to my own experiences with crashes. I found out a lot of useful information, and incorporated it into the program, which now I'm pretty sure will work correctly in normal crashes. (Still have yet to experience this in a full-screen game though.. but one day..)

Anyway, I should have the upload sometime in a day or two after I clean it up.

[Ascend4nt]

*EDIT 4 (I should come up with version #'s hey?):

Rewrote much of the program due to my own 'crash day' on XP here (some Macromedia Flash-related accident), now there are separate functions to detect if a window is unresponsive, I allow for certain conditions when explorer.exe is crashed to let this program terminate that (and restart it),I centralized 'debug' writes so they can be disabled or rerouted to a log file etc, and added attempts to alter a window's 'Always-on-Top' status in addition to minimizing it.

[montymintypie]

I'm really liking how this is turning out!

One feature request... Can you make it beep for every time you hit the hotkey? E.G. Different beeps/number of beeps for how many times the hotkey has been pressed? I was playing Gmod before and it froze, and I pressed once and heard nothing. After a while, I heard the high pitched beep. This made me wonder if for the other presses, when it doesn't beep, if I had actually pressed the hotkey for long enough.

Hope that made sense

[Ascend4nt]

montymintypie, thanks for the feedback.

Yeah, I too like the sound feedback 'notification'. Right now the Async version is the only one you need to worry about how long you press the keys down for though - otherwise you can be pretty sure my program is being activated each hotkey-presst. (the HotKey UDF makes certain of it)

I can add differing beeps and stuff, but I don't know at what point I can tell what the meaning/difference is between the Beeps If you come up with some Beep() ideas, let me know.. but I get confused.. beep low, beep high.. beep midrange? What does it all meeannn? hehe.. I'm not sure I'd be able to distinguish exactly what's going on.

The other problem with Beep is that it takes up processor time - AutoIT is frozen the whole time it's beeping, and I think I have 300ms beep's in there, which feels 'just long enough'. I suppose 3/10ths of a second isnt a big deal though..

So anyway, think about it, maybe give Beep() at differing volumes/time-lengths a try and see what you would recognize and what feels right. I'll think about it too in the meantime. Maybe I'll create a _AudioNotification() function and we can work off there just how to notify of things like 'no matching windows', 'attempt 1 received, located window, not locked up', 'attempt 2 received, same deal..', 'attempted minimize', 'attempted kill'..

[Ascend4nt]

Well it finally happened - I was able to fully test everything in three different crash situations, and again a rewrite was in order! (first post has update)

Here's the deal:

Trying to get the 'active' Window causes AutoIT to come to a halt (same for the Windows API call). I had to remove that, and just go through the entire loop of windows each time the hotkey is pressed. I do look for the 'active bit' in the Window's state though, and if that Window happens to match the criteria, it's put ahead of any other full-screen/maximized apps/games.

In addition to rewriting that, I added montymintypie's requested 'beep's in, hopefully making it pretty distinguishable what's going on. People without PC speakers are at a loss - but the source code is there (as well as 'SoundPlay()' - so have at it)

Also, I figured I'd attach my notes from what AutoIT functions fail or report invalid information (from the source code comments):

Anyway, enjoy!

--------------------------------------------------------------------------------------------------

-------------------- CRASH NOTES FROM EXPERIENCE --------------------

--------------------------------------------------------------------------------------------------

• 1. Using WinGetHandle("[ACTIVE]") will HANG this program for crashed/unresponsive apps, and for suspended apps, it will return an $hWnd of 0. The Windows API counterpart, 'GetForegroundWindow' fails the same way.

  Thus, this method of looking at the 'first' window was ditched.

  However, using WinGetState() on handles from WinList() will indicate which window is the active window ('active' bit). This is tracked along with the first full-screen/maximized window this program comes across. If both windows found match the given parameters, the 'active' window is chosen above the other.

• Using WinGetTitle() will also HANG this program for crashed/unresponsive/suspended apps. Luckily, since we no longer use the method listed in 1., we don't need to make that call (WinList() provides that info for us)
• WinSetOnTop() and WinSetState() on crashed/unresponsive programs MAY hang this program, and suspended apps will definitely hang it. This is why the double-check for an unresponsive program is performed, so we avoid that situation
• On HARD crashes, where explorer.exe itself crashes, WinGetProcess() will sometimes return Explorer.exe's Process ID. On these rare occassions, this program will terminate and restart explorer.exe if the app window is found unresponsive.

  From experience, that actually removed those apps from my screen!

  However, I'm VERY careful not to terminate Explorer.exe if one of it's windows meets the criteria (full-screen/maximized, and visible). The routine checks window Title and classname to be sure before it takes any action.

Edited July 12, 2009 by Ascend4nt

[montymintypie]

WOW!

What a big update! One time when I tested with Gmod, it was loading, and didn't minimise until it was finished. Hope this fixes it.

This excellent program just got better! I like the beep inclusion too.

This is now a permanent startup item for me.

P.S. Thanks for the PM, wouldn't have checked without it.

[Ascend4nt]

montymintypie,

I had an issue where I found a replicable game crash on a friend's PC and found the same situation - the program wouldn't 'react' until I had found a way to terminate the game on my own. It was due to the 'WinGetHandle('[ACTIVE]')' line. That one line would stop the program in it's tracks. So from experimentation with that and other crash situations, I was able to rewrite the codet so that there aren't any more situations that will freeze the program (I'm pretty confident of it now). I hope it works well for you and anyone else that tries it.

Thanks for all your feedback.