Download Methods for automatically locating data
Transcript
US006630946B2 (12) (54) United States Patent (10) Patent N0.: Elliott et al. (45) Date of Patent: METHODS FOR AUTOMATICALLY LOCATING DATA_C()NTAINING WINDOWS 4,827,406 A 4,870,644 A IN FROZEN APPLICATIONS PROGRAM (75) (U-S) Y E_1Ydeta1-t---l ----------- - , in 5,124,989 A Inventors: K Scott Je?'re C. Elliott, Perc Hillsboro, Carr Ti ard OR (US); OR Y > g ’ ’ 2 5,293,612 A > *Oct. 7, 2003 5/1989 Bischoff et al. .......... .. 711/153 9/1989 Sherry et al. ............ .. 714/47 2 , AND SAVING CONTENTS US 6,630,946 B2 say e a . . . . . . 6/1992 Padawer et al. i * . . . .. ..... .. 714/38 5// iomez O-me - et ' ' ' 'al' ' ' ' ' ' """""" '''" / 3/1994 Shmgai .................... .. 711/159 (List continued on next page.) (73) Assignee: Symantec Corporation, Cupertino, CA (Us) (*) Notice: OTHER PUBLICATIONS This patent issued on a continued pros- dA1an”SimPS0n> “Mastering wordpgrfecg ecution application ?led under 37 CFR OWS ’ SYBEX’ 1994’ pp‘ 497’ 4 3_4 & 5-2 for Win‘ ' _ 153w), and is Subject t0 the tWenty year Margaret Levme Young et al, WordPerfect 6.1 for Windows patent term provisions of 35 USC for Dummies”, IDG Books Worldwide Inc., 2nd Edition, 154(a)(2)_ 1993, pp. 335, 368* Subject to any disclaimer, the term of this (Llst Connnued on next page‘) gusenct liszxéengei) (5r adlusted under 35 ' ' ' ( ) y Primary Examiner—John Cabeca ays' Assistant Examiner—X. L. Bautista (74) Attorney, Agent, or Firm—Fliesler Dubb Meyer & (21) Appl. N0.: 09/438,076 (22) Filed: NOV. 10, 1999 Lovejoy, LLP (57) (65) A machine-automated system tries to save vital-data of a crashed or otherWise frozen application program by: (a) attempting to revive a program that has apparently become 51 ( Prior Publication Data US 2002/0169795 A1 Nov, 14, 2002 I t C17 ) (52) (58) n ' ' G06F 3 00 G 0 6F 12 00 """""""""""""" " / ’ / ABSTRACT froZen; (b) identifying the apparently-frozen program; (c) identifying one or more Windows Within the identi?ed US. Cl. ..................... .. 345/781; 345/803; 345/806; _ 345/853; 707/202; 711/161 Field of Search ............................... .. 345/326, 339, program that are most likely t0 immediately Contain data Which the user is likely to consider as vital and in need of Saving; (d) Sending one or both of a SAVE and a CLOSE 345/340, 356, 700, 764, 781, 853, 803, 806; 707/202—204; 709/313, 316, 317, 328; 711/161—162 command message to each of the identi?ed one or more Windows so as to thereby cause that Window to itself save its vital data contents and to thereafter gracefully close itself. A (56) R f e erences Ct d pro?ling database may be constructed for helping to identify the vital data-containing Windows of both popular (Well known) and obscure application programs. One such pro ?ling database has ID records Which de?ne parent/child 1 e U.S. PATENT DOCUMENTS 4,514,846 A 4/1985 Federico et al. ............ .. 714/45 hierarchy relationships betWeen vital data-containing Win 4,521,847 A 6/ 1985 Ziehm et al. ........ . . . .. 700/79 doWs and other Windows of various application programs. 4,580,232 A 4/1986 Dugan et al. ........ . . . .. 399/77 4,589,090 A 5/1986 Downing et al. 4,811,216 A 3/1989 Bishop et al. ............ .. 711/153 714/10 26 Claims, 7 Drawing Sheets APP 1m | m PROGRAM sKIFs NGDF wow nDucr 453 453 J 455 / US 6,630,946 B2 Page 2 Adaptec, Inc.; GoBack: The Power to Undo PC Problems— US. PATENT DOCUMENTS 5,321,824 A 5,335,344 * A 5,410,685 A 5,493,649 A 6/1994 Burke et al. .............. .. 711/220 8/1994 Hastings ....... . . . .. 4/1995 Banda et al. .. * 2/1996 Slivka et al. ..... 714/35 714/38 . . . .. 714/48 Adaptec, Inc.; GoBack: The Power to Undo PC Problems on Shared or Workgroup Computers—data sheet; http://www. adaptec.com/products/datasheets/gobackprofessionalhtml; 5,515,493 A 5/1996 Boston et al. . 5,526,485 A 5,530,864 A 6/1996 Brodsky .................... .. 714/38 6/1996 Matheny et al. ...... .. 709/328 X Jul. 21, 2000; pp. 1—3. 9/1996 Connors et al. .. 711/100 GoBack; 711/170 html; Oct. 16, 2000; pp. 1—2. Adaptec, Inc.; GoBack: Product Tour—restoring the system, * 5,559,980 A 345/807 data sheet; http://www.adaptec.com/products/datasheets/go back.html; Jul. 21, 2000; pp. 1—3. 5,561,786 A 10/1996 5,568,635 A 10/1996 Yamaguchi 5,581,696 A 5,581,697 A 12/1996 Kolawa et al. ............. .. 714/38 12/1996 Gramlich et al. ........... .. 714/35 5,696,897 12/1997 A 5,701,484 A Morse ........ .. Dong 711/171 ... ... ... .. * 12/1997 Artsy ......... .. 5,712,971 A 1/1998 Stan?ll et al. . 5,748,882 5/1998 A 5,812,848 A Huang .. ... ... .. . . . .. 9/1998 Cohen ........ .. 5,815,702 A 5,819,022 . . . .. 10/1998 5,857,204 A 5,857,207 A 5,911,060 A Bandat 714/16 703/22 ?le; http://adaptec.com/products/tour/goback3.html; Oct. Elliott .. ... ... .. . . . .. 3/2000 Chung et al. Elliott 705/30 ..... .. ... ... .. . . . .. 714/15 6,173,291 B1 * 1/2001 Jenevein ..... .. 6,182,243 B1 1/2001 Berthe et al. ............... .. 714/38 6,269,478 B1 7/2001 Lautenbach-Lampe . . . .. 703/22 707/202X et al. ........................ .. 717/127 B1 6,405,325 B1 6,438,709 B2 6,438,749 B1 goback2a.html; Oct. 16, 2000; pp. 1—2. goback2b.html; Oct. 16, 2000; pp. 1—2. Adaptec, Inc.; GoBack: Product Tour—recovering a deleted 11/2000 6,389,556 written ?le, step 1; http://www.adaptec.com/products/tour/ written ?le, step 2; http://www.adaptec.com/products/tour/ * 6,330,528 B1 html; Oct. 16, 2000; pp. 1—3. Adaptec, Inc.; GoBack: Product Tour—recovering an over 714/15 703/27 12/1999 A step 2; http://www.adaptec.com/products/tour/gobacklb. 709/100 Elliott ........ .. 6,009,258 A 714/34 714/47 6/1999 6,009,414 A * 12/1999 Hoshiya et al. 6,151,569 step 1; http://www.adaptec.com/products/tour/gobackla. 707/202 707/203 8/1999 Damani et al. 10/1999 Elliott et al. 6,044,475 Product Tour—introducing 1/1999 Lordi et al. 1/1999 Lo et al. 5,938,775 A 5,974,249 A A . . . .. GoBack: http://www.adaptec.com/products/tour/goback. html; Oct. 16, 2000; pp. 1—2. Adaptec, Inc.; GoBack: Product Tour—restoring the system, 712/244 . ... ... .. Inc.; 709/316 714/15 709/331 9/1998 Kannan et al. A Adaptec, 12/2001 Huang et al. .. 5/2002 Qureshi ... .. ... . . . .. Adaptec, Inc.; GoBack: Product Tour—recovering an over 16, 2000; p. 1. Adaptec, Inc.; ReZOOM: Technology Comparison; http:// adaptec.com/technology/overview/reZoom.html; Jul. 21, 2000; pp. 1—5. Adaptec, Inc.; ReZOOM Compatibility Update; http://ww w.adaptec.com/support/compatibility/rezoomhtml; Jul. 21, 703/22 2000; pp. 1—2. 714/15 Adaptec, Inc.; ReZOOM: Product Tour—Setup ReZOOM; http://www.adaptec.com/products/tour/reZoom1.html; Oct. 6/2002 Lin et al. .................... .. 714/15 8/2002 Poisner ...................... .. 714/23 8/2002 Chamberlain ............. .. 717/174 OTHER PUBLICATIONS Larry Brown et al, “Dynamic Snooping in a Fault—Tolerant Distributed Shared Memory,” IEEE, pp. 218—226.* “First Aid® 97 Deluxe, User Manual,” CyberMedia, Inc., 1996, pp. i—viii, 1—123. “Vertisoft FiX—ItTM For Windows 95,” User’s Guide, Verti soft System, Inc., Jun. 1996, pp. i—vii, 1—86. “WINProbe 95”‘ User Guide,” Quarterdeck Corp., 1996, pp. i—vi, 1—88. Adaptec, Inc.; GoBack: Product Tour—viewing your drive 16, 2000; pp. 1—3. Adaptec, Inc.; What resellers are saying about ReZOOm; http://www.adaptec.com/adaptec/testimonials/reZoom.html; Jul. 21, 2000; pp. 1—2. Adaptec, Inc.; ReZOOM: All—In—One Protection To Elimi nate PC Downtime—product overview; http://www. adaptec.com/products/overview/reZoom.html; Jul. 21, 2000; pp. 1—3. Adaptec, Inc.; ReZOOM: All—in—one Protection to Elimi nate PC Downtime—ReZOOM Features; http://www. adaptec.com/products/overview/reZoomfeatures.html; Jul. goback4.html; Oct. 16, 2000; pp. 1—2. 21, 2000; pp. 1—4. Adaptec, Inc.; ReZOOM: All—In—One Protection To Elimi nate PC Downtime—data sheet; http://www.adaptec.com/ products/datasheets/reZoom.html; Jul. 21, 2000; pp. 1—4. Adaptec, Inc.; GoBack Product Reviews; http://adaptec .com/products/overview/gobackreviews.html; Jul. 21, 2000; Adaptec, Inc.; ReZOOM Product FAQs; http://www. adaptec.com/products/faqs/reZoom.html; Jul. 21, 2000; pp. as it was in the past; http://www.adaptec.com/products/tour/ pp. 1—5. 1—5. Adaptec, Inc.; What GoBack Users are Saying; http://ww Adaptec, Inc.; ReZOOM: Product Tour—Setup ReZOOM, cont.; http://www.adaptec.com/products/tour/reZoom1b. w.adaptec.com/adaptec/testimonials/goback.html; Jul. 21, 2000; pp. 1—3. html; Oct. 16, 2000; pp. 1—3. Adaptec, Inc.; GoBack Product Awards; http://www. adaptec.com/products/overview/gobackawards.html; Jul. Adaptec, Inc.; ReZOOM: Product Tour—Testing Recovery; http://www.adaptec.com/products/reZoom2.html; Oct. 16, 21, 2000; pp. 1—3. 2000; pp. 1—2. Adaptec, Inc.; ReZOOM Multimedia Presentations; http:// www.adaptec.com/products/tour/rezoomim.htnl; Jul. 21, Adaptec, Inc.; ReZOOM: Product Tour—Using ReZOOM; http://www.adaptec.com/products/tour/reZoom3.html; Oct. 2000 p. 1. Adaptec, Inc.; GoBack: The Power to Undo PC Problems— 16, 2000; pp. 1—3. Adaptec, Inc.; ReZOOM: Product Tour—ReZOOM Recov product overview; http://www.adaptec.com/products/over ery; http://www.adaptec.com/products/tour/reZoom4.html; view/goback.html; Jul. 21, 2000; pp. 1—3. Oct. 16, 2000; pp. 1—3. US 6,630,946 B2 Page 3 Pietrek, M., “Windows TM 95 System Programming SecretsTM,”IDG Books Worldwide, Inc., 1995, pp. 692—694. Richten J~> “Advanced Wind9WSTM> The Developer’s Guide US. patent application Ser. No. 09/438,135, Lopez et 211., ?led Nov. 10, 1999. US. patent appliction Ser. No. 09/438,020, Zeigler et 211., to the WIN 32® API for WindoWs NTTM 3,5 and WindoWs ?led NOV_ 10, 1999_ 95,” Microsoft Press, Copyright 1995, pp. 809—838, 848—858. * cited by examiner U.S. Patent Oct. 7, 2003 Sheet 2 0f 7 US 6,630,946 B2 OS HANDLE= 991014 -J211a 213 F [OUTERMOST WINDOW] I 2148 OS HANDLE= 991019 CAPTION: "WORD PROCESS" I I 214b 2146 kl PW HANDLE= 991014 Tlizmd CLASS:“WORDPERFECT.7.32" CONTROL ID ="[none]" | T2146 2141 | ....OTHER ATTRIBS Y 212 ~ TT [TOP MENU BAR WINDOW] Os HANDLE= 991021 CAPTION: "CS7_Command_Ba1" Q———— PW HANDLE= 991019 215 I 2158 4| L 2151, I 2150 —§I 215d CLASS= "MSO__COmmand_Bar" —I5 2156 CONTROL ID ="A.1" TJI 215f ....OTHER ATTRIBS 4| I’ 215 I [TOP RIGHT PUSHBUTTONS] I I O8 HANDLE= 991022 I I CAPTION: "[none]" a—— PW HANDLE= 991019 I CLASS= "BUTTONS" | II I 216 J a I -216b I 2166 —'SI 216d J 2168 I CONTROL ID = A2 II __!_5' ' ....OTHER ATTRIBS T5’ I 2161‘ f 211 I 2178 OS HANDLE= 991023 [DOCS CONTAINER] I 217b CAPTION: "[0009]" | T 217C | y 217d I 2178 @-——- PW HANDLE= 991019 CLASS= "MD|_CL|ENT' CONTROL :0 ="A.3" I g" 21” ....OTHER ATTRIBS 4 [DOC_1 WINDOW] I fm I 2183 0s HANDLE= 991024 I .218b CAPTION: "Document 1" I 2180 I F PW HANDLE= 991023 g I CLASS: "WP__DOC_FRAME" 218d if I 2188 I I CONTROL ID ="B.2" J 218T ' OTHER ATTRIBS TU U.S. Patent F_ Oct. 7, 2003 3 _9-__ Sheet 3 6f 7 \ US 6,630,946 B2 340 3 O RuN 310 NEW APPLICATION <5 ———— -; PROGRAM : I FOR DATABASE LOCATING VITAL WINDOWS : g 342 I l POPULAR COMMERCIAL APPLICATION I : 311 344 I PROGRAMS f\\_/ l I OTHER COMMERCIAL MANUAL ID ; OF VITAL I WINDOW(S) I : APPLICATION 312 PROGRAMS \/ : ; 45 GEN AUTO lI ENABLE ID I I I FOR VITAL l I I I I I I 318 l l l | 350 PGM_NAME='WORDX.“32" NAV_PATH= {OUTER CLASS= "WwB"}/ {LEVEL_A CLASS="MDI"' AND ID RECORD -330 LEVEL_A CAPTION="'MENU*"}/"I {LEVEL_C CLASS: "WPDOC?.32"} OBSCURE APPLICATION PROGRAMS SAC_MSSG="WM__CLOSE" L 355 / USE TO 360 AUTO ID VITAL DATA WINDOWS SOK_MSSG="ENTER_KEY" ‘~35? W U.S. Patent 0a. 7, 2003 7D 440' Sheet 4 6f7 00 US 6,630,946 B2 . 4 APPLICATION PROGRAM RUNNING 443 441 USER GUARD PGM PERCEIVES A DETECTS A FREEZE FREEZE 444 442 AUTO INVOKE OF UN-FREEZE DIALOG MANUAL INVOKE OF UN-FREEZE TERMINATE SKIP SAVING OF WORK PRODUCT ANTI-FREEZE VITAL~SAVE 462 453 463 REVIVE ATTEMPT 410 464 468 \'\ REVIVE ATTEMPT I 465 USER MANUALLY SAVES WORK VITAL PGM AUTOMATICALLY IDENTIFIES & SAVES PRODUCT WORK PRODUCT INTELLIGENCE DATABASE U.S. Patent 0a. 7, 2003 Sheet 5 0f 7 US 6,630,946 B2 Fig. 5 sTART AT TOP OF 5/1O ~—>‘ ID RECoRDs DATABASE (E.G., 310/410) 502 501 V sELECT A NExT ID RECoRD 511 ’\ (E.G., 35o) NONE ' """""""""""" ‘ if | 519 l 525 | I TEsT FOR PGM_NAME SATISFACTION _ OK \ 522 EXIT V > \ 529 START AT HIE RARCHY / 530 A NOT SATISFIED ——————————— — - LEVEL OF ouTERMosT FRAME WINDOW NOT TOP V J GET NAV SATISFACTION RULE J40 FOR CURRENT HIERARCHY LEvEL FROM DATABASE T53‘; / l DECREMENT FIND ANExT WINDOW AT CURRENT HIERr“ ARCHY LEvEL THAT sATIsFIEs NAV RULE 550 “'52 LEVEL A ' FOR CURRENT HIERARCHY LEvEL S NONE \ \.\ ’ MARK CURRENT HIER LEvEL As EXHAUSTED 555 wAs THIS LAsT YES f] CHILD IN NAV_PATH 557 569 560 570 'NCREMENT RETURN 0s HANDLE OF CURRENT wINDow H'ER LEVEL AS A MATCH REsULT I EXIT 559 U.S. Patent 0a. 7, 2003 US 6,630,946 B2 Sheet 6 0f 7 610 TRY TO IDENTIFY NAME OF JUST-REVIVED PRO FAILED GRAM I I I f’ 619 I SELECT ONLY ID RECORDS I 611 ’\ (E.G,, 350) WITH MATCHING I | PGM NAME I TRY TO ISOLATE A RULES RECORD 620 < CONTINUE > T0 STEP 640 WHOSE NAV_PATH SATISFACTION RULES MOST TIGHTLY CONFORM WITH ONE OR MORE TO-WINDOW NAVIGA TION PATHS FOUND WITHIN THE JUST REVNED 8. IDENTIFIED PROGRAM OR WITHIN DESKTOP A, 641 FOUND /\J 2 v 6 1 640 P’ DE-SUSPEND THE JUST REVIVED PROGRAM 440/124 SO THAT THE OPERATING SYS TEM BEGINS GIVING TASK TIME TO THE REVNED PROGRAM FAILED SEARCH THE DATABASE ) 410 AND TRY TO LOCATE WITHIN DATABASE 410, A 630 GENERALIZED OR OBSCURE RULES RECORD WHOSE SATISFACTION RULES CONFORM IN A REL ATIVELY TIGHT WAY WITH ONE OR MORE OF TO WINDOW NAVIGATION PATHS FOUND WITHIN THE JUST-REVIVED & IDENTI FIED PROGRAM OR WITHIN DESKTOP FAILEDh 639 EXIT FOUND 631 U.S. Patent Oct. 7, 2003 Sheet 7 0f 7 gig“; Ff US 6,630,946 B2 Fig. 6B 640 SELECT A FIRST, OR THE NEXT BEST WINDOW THAT IS GUESSED BY ANY ONE OR MORE OF 645 STEPS 601-640 TO CONTAIN V‘TAL DATA WHICH V Is IN NEED OF SAVING -\ I W \ OPTIONALLY MONITOR THE wINOOws ENvI RONMENT TO SEE IF 661 650 THE SAVlNG/SHUTTING- A V gg‘mvvgwzg‘gggf OR OTHER MESSAGE THAT NEEDS To BE RESPONDED To IN SEND MESSAGE(S) (E.G., wM_CLosE) OR INSTRUC 1 TIoNs To WHAT Is GuEssEO TO BE A vITAL DATA \ CONTAINING WINDOW FOR CAUSING THAT GuEssEO WINDOW TO ITSELF sAvE ITs OwN DATA ORDER To KEEP THE SAVE~AND-SHUT- _ _ DOWN PROCESS MOv- ING FORWARD UNABATED \ ’ \ I ’ \f ON AN AUTOMATIC _ - T ' ' ' " T T ' ' T T T. I : INHERENTLY, OR OPTIONALLY, cAusE GUESSED wINOOw TO SHUT ITsELF DOWN I As CLEANLY As POSSIBLE 1 K TO EXTENT POSSIBLE - ‘ \ : TTTTTTTTTTTTTTT "' 660 BASIS, ANswER THE L’_\ WAIT FOR SAVE-AND/OR-CLOSE DIALOG BOX OR OTHER 655 T0 COMPLETE /\ MEssAGE IN A MANNER wHICH WILL KEEP THE 670 SAVE-AND-SHUT-DOWN f\ PROCESS MOVING FORWARD UNABATED ' 675 554 If AUTOMATICALLY ANY MORE WINDOWS DETECT FURTHER To SAVE-AND-CLOSE '2 FREEZINGS AND AUTOMATICALLY ATTEMPT To AGAIN REvIvE THE RE YES N0 \/ INSTRUCT THE usER To FROZEN PROGRAM sHuT DOWN THE PICK THE OPTION IN THE PROCESS-ABATING DIALOG BOX THAT IS LEAsT LIKELY TO BLOCK CON- so As TO CONTINUE THE CARRYING OuT OF THE SAVE AND~SHUT-DOWN MAIN PROGRAM TINUED CARRYING OUT OF THE SAVE-AND- ggggggi 538525. SHUT_DOWN PROCESS WAL DATA _ CONTAINING WIN_ DOW ' r] 668 \/-\ 680 682 / RELAuNcH A FRESH (NOT CORRUPTED) COPY OF THE FROZEN-ANDHAFTERWARDS REvIvEO PROGRAM /” 672 / A684 RE-LOAD INTO FRESH COPY OF THE PROGRAM, THE DATA THAT HAD BEEN SAVED US 6,630,946 B2 1 2 METHODS FOR AUTOMATICALLY LOCATING DATA-CONTAINING WINDOWS IN FROZEN APPLICATIONS PROGRAM AND SAVING CONTENTS Preemptive multitasking systems may be characteriZed as those in Which an operating system (OS) has supervisory control over the concurrently executing programs and the OS limits the length of time that each given application program has for using system resources such as a CPU (Central Processing Unit) or other data processing means. BACKGROUND Examples of preemptive multitasking OS’s include 1. Field of the Invention Microsoft WindoWs95TM, Microsoft WindoWs98TM and The invention relates generally to computer systems that concurrently execute plural application programs on a pre emptive multitasking basis. Microsoft WindoWs NTTM, all of Which are available from 10 The invention is directed more speci?cally to multitasking systems Wherein the execution of a given application pro threaded execution, a program begins executing as a ?rst, main thread and optionally generates ancillary threads that gram may become frozen or may otherWise halt unexpect edly and for Which it is desirable revive the froZen/-halted run concurrently and interact With one another through 15 application program at least partially so as to enable non encounter an unexpected problem Which halts its normal frozen program. The invention is directed even more spe execution either in a main thread or an ancillary thread. 20 2a. Cross Reference to Related Patents The disclosures of the following US. patents are incor services Without the ability to handle such unavailability, (c) the program jumps into a nonsense stream of execution 25 RATUS FOR UNFREEZING AN APPARENTLY FROZEN APPLICATION PROGRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM; and (B) US. Pat. No. 5,974,249 issued Oct. 26, 1999 to Scott Elliott et al, and entitled, ZERO FOOTPRINT METHOD 30 AND APPARATUS FOR EXPANDING ALLOCATED MEMORY SPACE OF A PROCESS USING A VIRTUAL MEMORY AREA. 2b. Cross Reference to Co-Pending Patent Applications The disclosures of the folloWing Co-pending, US. patent applications (each oWned by the oWner of the present code, (d) the program invokes a no-time-out Wait for an event that never happens, (e) the program enters into a deadlock embrace, and so forth. This is a nonexhaustive list of possible causes. When such execution-halting events occur, artisans some times refer to the halted program as being ‘stuck’ or ‘froZen’ or ‘crashed’ or as having encountered a ‘fatal error’. Dif ferent ?avors of these terms are sometimes associated to one class of cause as opposed to another. Here, the terminology 35 application) are incorporated herein by reference: (A) US. Ser. No. 08/938,204, ?led Sep. 26, 1997, by inventor Scott Elliott and originally entitled COMPUTER Examples of causes for such problems include those in Which: (a) the program attempts to access restricted (privileged) or unavailable areas of memory areas, (b) the program makes calls to unavailable system functions or porated herein by reference: (A) US. Pat. No. 5,911,060 issued Jun. 8, 1999 to Scott Elliott, and entitled, COMPUTER METHOD AND APPA exchanges of semaphores. During execution, a given application program may volatile saving of Work product produced so far by the ci?cally to the problem of hoW to appropriately save Work product items of a just-revived application program. Microsoft Corporation of Redmond, Wash. These OS’s also permit multi-threaded execution of programs. In multi ‘froZen application’ Will be generically applied to any and all situations in Which the user of a given application program reasonably believes the program is stuck and therefore prevents saving of Work product irrespective of the exact 40 cause and irrespective of Whether that belief is accurate in fact. METHOD AND APPARATUS FOR ACCESSING AN The end-user (e.g., novice user) of a computer system APPLICATION PROGRAM WHICH HAS BECOME typically doesn’t care What the speci?c cause is that has led UNRESPONSIVE TO MESSAGES FROM THE OPERAT him or her to believe that they can no longer save Work ING SYSTEM OR INCURRED A FATAL ERROR, Which product. Such a user instead generally recogniZes the ‘fro application later issued as US. Pat. No. 6,009,258; and 45 Zen’ condition as an apparently sudden refusal by the given (B) U.S. Ser. No. 09/275,171, ?led Mar. 24, 1999 as a application program to respond appropriately to keyboard divisional of US. Ser. No. 08/937,629, ?led Sep. 26, 1997 by inventor Scott Elliott and originally entitled COM strokes or to mouse clicks or to other user interface inter actions (Which interactions can include voice commands, hand gestures, and so forth). PUTER METHOD AND APPARATUS FOR UNFREEZ ING AN APPARENTLY FROZEN APPLICATION PRO GRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM. The presence of a froZen program does not generally pose a major problem to the overall operations of a preemptive multitasking system. In such systems, other, concurrently 2c. Copyright Notice executing application programs can continue to run in This application includes one or more listings of computer normal fashion even though a given application has actually become froZen or has actually crashed (as opposed to programs. The assignee of the present application claims certain copyrights in said computer program listings. The assignee has no objection, hoWever, to the reproduction by others of these listings if such reproduction is for the sole purpose of studying it to understand the invention. The assignee reserves all other copyrights in said program list 55 situations Where the program is ?ne and the user merely believes it has become stuck). The end-user continues to have access to operating system services and to the resources of non-froZen application programs. (For 60 example, in a WindoWs95/98TM environment the user may 65 hit the Alt-Tab key combination to sWitch to the next task.) The user may choose to simply end the tasking of the apparently-froZen program and to thereafter restart the pro gram afresh from its basic start-up state. Sometimes, this close-and-restartiafresh option is not an ings including the right to reproduce the corresponding computer programs in machine executable form. 3. Description of Related Art Multitasking computer systems may be characteriZed as those that alloW multiple programs to execute in overlapping fashion so that it appears the programs are all running at the same time. attractive one for the end-user. It may be that the end-user did not, or believes he did not, save to nonvolatile memory US 6,630,946 B2 3 4 (e.g., to hard disk), a segment of Work that he/she last end user may ?nd that the mouse-driven SAVE FILE func tion of the program has become inoperative. The user may performed With the application just before the given appli cation became froZen. Closing-and-restarting the froZen not knoW What else to do for saving the Work product data. Also, the user may have multiple spreadsheets or multiple program afresh may mean that the unsaved Work may be lost forever. Many hours of Work may have to be painfully redone to reconstruct the state of the application just before it apparently became froZen. In some instances, the pre freeZe state of the application may represent non replicatable Work product such as data that had just been captured and/or transformed in real-time. other Work product objects (e.g., Word processor documents) left open and in need of saving. The user may become confused and try to use inoperative parts of the just-revived program instead of immediately saving all unsaved Work product. 10 The present invention provides methods and systems To remedy this predicament, various un-freeZing tech niques have been developed. These try to revive the froZen/ Which may be used as automated alternatives to alloWing an crashed program at least to a suf?cient level such that process in a just-revived program. end user to manually control the Work product saving unsaved Work product may be accessed and saved either Wholly or partially. Examples of such un-freeZing tech A number of separate aspects of a multi-threading, patent applications. WindoWs-oriented operating system (OS) are employed No currently knoWn revival technique is 100% effective for all possible forms of application program. One may make an analogy to attempts to revive a human patient by here. These include: detection of a possible freeZe and attempted revival of an apparently-froZen program, analysis of the parent/child WindoWs hierarchy in the just-revived CPR (cardio-pulmonary resuscitation) after the patient suf fers a cardiac arrest. In some cases, the patient is fully revived. In other cases, the patient is revived but still suffers from serious complications. And in yet further cases, even heroic attempts to revive the patient regretfully prove unsuc program, and automatically passing of messages to appro priate child WindoWs to cause those WindoWs to themselves save their data contents and/or immediately thereafter close. When an un-freeZe request is presented, and a Vital 25 SaveTM option is selected (VitalSaveTM is a trademark of cessful. In so far as reviving a froZen application program is Symantec Corp.), an appropriate revival procedure (Which concerned, the end goal is not to keep the application could include doing nothing) is automatically selected and program alive and Working as long as possible, but rather to carried out. Thereafter, an automatic identi?cation is made of one or more WindoWs of the just-revived program that keep it alive long enough so that vital, but still unsaved, Work product can be saved. most probably contain (immediately in such identi?ed One un-freeZing technique tests the apparently-froZen WindoWs), vital data that the user Would most likely Want to application to see if the cause of the freeZe is a ‘soft event’ save. One or both of a SAVE and CLOSE message is (Where the application continues to respond to messages from the OS) or a ‘hard event’ (Where the application is not longer responding to messages from the OS). If it is a ‘soft event’, the un-freeZing technique may try to CLOSE or SUMMARY OF THE INVENTION 15 niques include those disclosed in the above-cited patents and automatically sent to each identi?ed one of the vital-data 35 containing WindoWs so as to cause that WindoW to itself save its oWn vital-data, and thereafter optionally close itself. A machine-implemented, vital-data saving method in accordance With the invention comprises the steps of: (a) CANCEL the currently ‘active’ WindoW under the theory that such an ‘active’ WindoW is simply a hidden dialog box that is expecting a user response, but is not getting it because attempting to revive a program that has apparently become froZen and identifying that apparently-froZen program; (b) the user does not see the hidden dialog box. If the cause of the freeZe is determined to be a ‘hard identifying one or more WindoWs Within the identi?ed program that are most likely to immediately contain therein data Which the user is likely to consider as vital and in need of saving; (c) sending one or both of a SAVE and a CLOSE event’, the un-freeZing technique may try to continue the execution of the froZen application program by entering the execution stream of the froZen program at a point Where 45 command message to each of the identi?ed one or more continued execution Will probably preserve the application’s WindoWs so as to thereby cause that WindoW to itself save its state just before the encounter With the freeZe-causing event. HoWever, even if this attempt is fully or partially successful, vital data contents and to thereafter optionally close itself. Other features and aspects of the invention Will become determining speci?cally What data Within the revived pro gram should be saved and exactly hoW to go about saving it is still a problem. Conventionally, after a revival technique is applied to a apparent from the beloW detailed description. BRIEF DESCRIPTION OF THE DRAWINGS The beloW detailed description makes reference to the ‘hard’ failure event, a message is sent to the user to go ahead and try to immediately save their Work product to nonvola tile memory and to then immediately shut doWn the appli accompanying draWings, in Which: 55 cation program. In some instances, the end user ?nds that these instructions are very easy to folloW. The application program appears to be fully resuscitated and the end user invention; FIG. 2Ais a block diagram of a computer system that may may quickly forget that the program just suffered a serious be con?gured to operate in accordance With the invention; FIG. 2B is an example of a WindoWs hierarchy chart; problem. The user may be able to easily maneuver the cursor to a SAVE FILE function on the program’s menu bar and invoke a ?le saving operation. Sometimes the user may be so lucky as to be able to continue Working as if nothing FIG. 3 illustrates a database building system in accor dance With the invention; Wrong had just happened, although such continuing of Work de?es the instructions given to the user. In other cases, the end user’s ability to folloW the post revival instructions turns out to be more complicated. The FIG. 1 is a perspective vieW shoWing a computer system that may be con?gured to operate in accordance With the FIG. 4 is a How chart shoWing hoW a vital save activation 65 ?ts in Within a composite of other revival and save options; FIG. 5 is How chart shoWing details of a vital save operation in accordance With the invention; and US 6,630,946 B2 5 6 FIGS. 6A—6B combine to de?ne a How chart showing broader aspects of a vital save operation in accordance With the invention. grandparent WindoW frame 114 are referred to herein as LeveliA inner frames or more simply as LeveliA ‘parent’ WindoWs. Immediate children of the LeveliA inner frames DETAILED DESCRIPTION simply as IJeveliB child WindoWs. Each LeveliB WindoW are referred to herein as IJeveliB inner frames or more may have its oWn, LeveliC children and so forth. Atree-like FIG. 1 illustrates a perspective vieW of an overall com organiZational chart (see FIG. 2B) may be draWn to shoW puter system 100 that may be programmably con?gured to Which WindoW is a child of Which other WindoW. Such a chart is knoWn in the art as a WindoWs hierarchy chart. operate in accordance With the invention. This vieW Will be used to explain a dilemma that can confront users When an By Way of a more concrete example, consider in FIG. 1, the topmost menu bar 115 in the application program in-use application program freezes or crashes before the user has had a chance to nonvolatily save Work that is in progress. WindoW 114. This bar 115 Will normally appear to a user as The illustrated computer system includes a display moni tor 110, a computer housing 120, a keyboard 130 and a a seamless and integral part of outermost WindoW 114. HoWever, for purpose of this disclosure, bar 115 is shoWn for mouse 140. The illustrated user input and output devices 110, 130 and 140 are merely examples. Other to-user output devices and from-user input devices may, of course, be used 15 What, under usual circumstances, it really is to the operating system, namely, a LeveliA child of grandparent WindoW in addition to or in place of the illustrated devices. Mouse 114. Menu bar 115 is also referred to herein as a ParentiA.1 WindoW so as to distinguish it from other IJeveliA children 140 for example can be replaced by or supplemented With of grandparent WindoW 114. other graphically-oriented user input devices such as Consider next the combination of the main WindoW’s “minimize” button (symboliZed as a minus sign in a square), trackballs, touch pads, joysticks, and so forth. Voice input and/or output interfaces are contemplated in addition to the illustrated visual and tactile interfaces. Display monitor 110 includes a display screen 111 that can display a number of graphical items including a desktop layer and an overlying, opened application WindoW 114. its “shrink” button (shoWn as tWo overlapped rectangles in a square) and its “close” pushbutton (symboliZed as an X in a square). These are illustrated in respective left to right 25 order Within puZZle piece 116. This puZZle piece 116 Will normally appear to a user as a seamless and integral part of (Reference symbols that are braced by square brackets are not part of What is displayed on the screen 111.) In the outermost WindoW 114 that is placed in the upper right corner of frame 114. HoWever, for purposes of this illustrated example, the opened application WindoW 114 disclosure, the pushbuttons part 116 is shoWn for What it really is to the OS, namely, another IJeveliA child of grandparent WindoW 114. Pushbuttons part 116 is also contains information belonging to a running Word process ing program 124, Where the latter program 124 has the ?ctional name, WORD PROCESS. The actual Word pro cessing program could be Microsoft WORDTM, or Corel referred to herein as a ParentiA.2 WindoW. Alternatively, each of the separate pushbuttons in puZZle piece 116 may be a separate IJeveliA child WindoW. This explanation is just WordPerfectTM, or any one of a host of other commercially available Word processing programs. In the more concrete 35 by Way of illustration and does not limit the numerous Ways example given beloW, it Will be assumed to be WordPer fectTM version 7.x. The application WindoW 114 could alter natively have contained a spreadsheet program (e.g., Microsoft EXCELTM), a picture-draWing program (e.g., Adobe IllustratorTM), an Internet broWser program (e.g., Microsoft ExplorerTM), an electronic mailing program (e.g., Qualcomm EudoraTM) or any other such application pro gram. The example of a Word processing program is used in Which parent and child WindoWs may be interlaced to form a composite display object 114—119. Consider next, a dashed rectangle 117 that is shoWn inside the con?nes of grandparent WindoW 114. The borders of some WindoWs may be invisible to the end user even though they are knoWn to the operating system. Dashed rectangle 117 represents such an invisible-borders WindoW that is a further LeveliA child of grandparent WindoW 114. This here because many computer users are at least familiar With this type of application program. 45 Application WindoW 114 normally appears as being con tinuously ?lled With other items such as vertical and hori invisible-borders WindoW 117 is also referred to herein as the ParentiA.3 WindoW and also as a ‘documents container’ (for reasons that Will be apparent shortly). Besides WindoWs Zontal scroll bars, ruler bars, tool bars (not all shoWn), and that have displayed areas Which are visible to the end user, some programs (e. g., 124) can have hidden WindoWs that are a top menu bar 115. The top or main menu bar Will typically kept behind other WindoWs and are thus completely invisible have menu-dropping areas such as FILE, EDIT, VIEW, FORMAT, etc. This is common for example in programs running under Microsoft WindoWs98TM or Microsoft NTTM. The display of WindoW 114 Will normally not have the appearance of separated puZZle pieces such as is shoWn in FIG. 1. HoWever, in truth the contents of What appears to be a unitary application program WindoW such 114 are usually to the end user. (As an extension to this point, it may be noted that one of the more common problems that novice users encounter When they think their application program has ‘crashed’ is When an active WindoW becomes hidden behind a passive WindoW, and the hidden active WindoW is 55 Waiting for a user input, such as a click on an ‘OK’ pushbutton. The application program Would run just ?ne once the ‘OK’ pushbutton of the hidden dialog box is a cleverly integrated set of puZZle pieces, Where the puZZle pieces are formed from other WindoWs, and WindoWs Within those WindoWs and so forth, all of these separate puZZle pressed. But the user does not see this ‘soft’ defect and pieces being neatly tiled together to de?ne a composite therefore does not realiZe that it simply this failure to respond ‘OK’ Which is causing the program to appear display object. The end user may not be aWare that many parts of What appears to be a smoothly integrated main froZen.) application WindoW 114, are instead seen by the OS as a dren of their oWn. In the illustrated example, WindoWs 118 and 119 are LeveliB children of the ParentiA.3 WindoW collection of separate WindoWs. For purpose of reference, the outermost WindoW frame in FIG. 1 is referred to herein as the grandparent WindoW 114. Immediate and hierarchical children of this outermost, As explained above, LeveliA WindoWs may have chil 65 (117). Scroll bars, minimiZation pushbuttons and further such items Within WindoWs 118 and 119 may constitute LeveliC children of the respective LeveliB WindoWs 118 US 6,630,946 B2 7 8 and 119. However, it is not necessary here to detail their inner structures because We Will be focusing instead on the data contents of the LeveliB WindoWs 118 and 119. In the illustrated example, We assume that child WindoW 119 contains Word processor-produced text for a ?rst ?le or ‘document’ named DOCUMENTiB.3.1. Child WindoW 118 similarly contains Word processor-produced text for a sec ond ?le or document named DOCUMENTiB.3.2. These ?ctitious document names are selected here to simplify the particularly if the skilled user is not intimately familiar With the inner Workings of the ?le-saving functions of the just revived program 124‘. In the state of panic, the novice and/or advanced user may try to invoke operations that overly stress the just-revived program 124‘ and cause it to freeZe again, thereby Worsening the situation. The present inventors have found through experimenta tion that it is highly advisable, immediately after a program (e.g., 124) has apparently become froZen and has apparently just been revived, to perform the folloWing steps: (1) identify those child WindoWs (e.g., 118 and 119) of the task of understanding that the text of DOCUMENTiB.3.1 is held Within a ?rst LeveliB ‘child’ (WindoW 119) of the third LeveliA parent WindoW 117 and that the text of apparently just-revived program 124‘ that contain data in need of saving; and DOCUMENTiB.3.2 is held Within a second LeveliB ‘child’ (WindoW 118) of the same ParentiA.3 WindoW 117. Normally, one Would see a user-movable cursor (not 15 containing WindoW. shoWn) displayed on screen 111 in the form of an arroWhead or the like that is made movable over the other displayed From among the three possibilities of sending only a SAVE message, sending a SAVE and thereafter a CLOSE message, items in response to user activation of the mouse 140 or of and sending only a CLOSE message, the present inventors another such from-user input device. HoWever, We assume have found through experimentation With commercially popular application programs that the last option of sending here that our exemplary Word processing program (124) has just suffered a freeZe or a crash just at the time that the user Was typing in some additional text into DOCUMENTi only a CLOSE message Was the most effective and easily implemented approach. B.3.1 (119) at the position of the illustrated, text-insert icon 125. The user had not yet saved this neW text (e.g., “bbbb . . . ”) or some additional text (e.g., “eeee . . . ”) that 25 interfering and perhaps doing something else. The auto After the freeZe, the user alloWed an unfreeZing program mated mechanism of the invention persistently tries to immediately save as many pieces of Work-in-progress that it such as Symantec CrashGuardTM (Which is available from Symantec Corp. of Cupertino, Calif.) to attempt an unfreeZe operation on the just-froZe Word processing program 124. The attempted unfreeZe operation Was able to partially revive the just-froZe application program 124. The just OS. HoWever, for unknoWn reasons, the just-revived appli The present inventors have further found that it is also highly advisable to automate this WindoW closing process in a Way Which generally prevents a panicked user from had just been typed into DOCUMENTiB.3.2 (118). revived application program, noW referenced as 124, is able to respond to some simple, test messages sent to it from the (2) send in the recited order, one or both of a SAVE and a CLOSE message directly to each such data can to a nonvolatile storage means such as a local magnetic hard disk or a netWorked ?le server or other such Work preserving means. More details are given after We ?rst describe a typical hardWare and softWare con?guration. Referring noW to FIG. 2A, a possible method for inter 35 cation program 124‘ is not fully functional. As an example of What such partial nonfunctionality might entail, assume that the cursor arroWhead that normally connecting components of computer 100 is shoWn schemati cally. Computer 100 may include a central processing unit (CPU) 150 or other data processing means (e.g., plural processors), and a system memory 160 for storing immediately-executable instructions and immediately moves on screen in response to mouse movements fails to accessible data for the CPU 150 or other processors. System shoW up inside WindoW 114. A novice user may react in a memory 160 typically takes the form of DRAM (dynamic random access memory) and cache SRAM (static random access memory). Other forms of such high-speed memory may also be used. A system bus 155 operatively intercon panicked Way after coming to believe that because the cursor arroWhead is invisible, and even though the unfreeZe opera tion had executed successfully, he or she still cannot invoke the SAVE function that Would normally be provided in GUI 45 nects the CPU 150 and system memory 160. style from Within a drop-doWn menu (not shoWn) that Computer system 100 may further include non-volatile unfurls from the FILE portion of menu bar 115 after the user moves the cursor arroWhead over the FILE item (in bar 115) and clicks thereon With the mouse 140. A more advanced mass storage means 170 such as a magnetic hard disk drive, a ?oppy drive, a CD-ROM drive, a re-Writeable optical drive, or the like that is operatively coupled to the system bus 155 for transferring instructions and/or data over bus 155. Instructions for execution by the CPU 150 may be introduced into system 100 by Way of computer-readable user may come to realiZe that ?le contents can still be saved by using an alternate method for invoking the FILE function, such as pressing on the Alt and F keys of the keyboard 130. Sometimes this alternate method Works. Sometimes it media 175 such as a ?oppy diskette or a CD-ROM optical doesn’t. That may depend on Whether or not the main menu WindoW 115 is able to send messages to the B.3.1 document WindoW 119 by Way of the grandparent WindoW 114 of the just-revived program 124‘. 55 platter or other like, instructing devices adapted for opera tively coupling to, and providing instructions and data for the CPU 150 (or an equivalent instructable machine). The computer-readable media 175 may de?ne a device for cou Alternatively, assume that the arroWhead shaped cursor pling to, and causing system 100 to perform operations in (not shoWn) does appear Within grandparent WindoW 114 but accordance With the present invention as further described herein. either the FILE drop-doWn menu does not unfurl in response to mouse clicks on FILE, or if it does, the computer fails to react to mouse clicks on the SAVE item (not shoWn) of that unfurled drop-doWn menu. Once again, the novice user may react in a panicked Way after coming to believe that, even though the unfreeZe operation had been run, he or she has lost all Work product that has been created since the last save to hard disk. Even a user of advanced skills may panic, System 100 may further include input/output (I/O) means 180 for providing interfacing betWeen system bus 155 and peripheral devices such as display 110, keyboard 130 and mouse 140. The U0 means 180 may further provide inter 65 facing to a communications netWork 190 such as an Ethernet netWork, a SCSI netWork, a telephone netWork, a cable system, or the like. Instructions for execution by the CPU US 6,630,946 B2 9 10 150 may be introduced into system 100 by Way of data signals transferred over communications netWork 190. Com corresponding parent and can thereby provide a back link to the parent WindoW; (d) a ‘class name’ 214d Which de?nes certain behavioral attributes of the WindoW; (e) a ‘control identi?er’ 2146 that may optionally be assigned to the WindoW by its parent so the parent can distinguish among its munications netWork 190 may therefore de?ne a means for coupling to, and causing system 100 to perform operations in accordance With the present invention. The instructing signals that are transferred through the communications netWork 190 for causing system 100 to perform said opera various children if there is more than one; and further attributes such as ‘style’ bits Which turn various aspects on tions may also be manufactured in accordance With the present invention. System memory 160 holds executing portions 161 of the or off and rectangle siZe/location ?elds Which indicate the siZe and location of the corresponding WindoW. It is to be 10 operating system (OS) and of any then-executing parts of memory that conforms fully or partially to the hierarchy chart 200 shoWn in FIG. 2B. In the WindoWs95/98TM environment, a Spy++TM program, Which is available as part of Microsoft’s standard programming tools, can be used to spy on a program’s WindoWs hierarchy and to display a WindoWs hierarchy tree similar to What is shoWn in FIG. 2B. Class names such as found in regions 214d, 215d, 216a' application programs 165. The application programs 165 generally communicate With the operating system by Way of an API (application program interface) 161a. One of the operations that is routinely carried out, is the passing of object-oriented messages from one WindoW object (not shoWn in FIG. 2A) to another such object Within system memory 160. Often the OS 161 Will act as an intermediate carrier of such messages. System memory 160 may include memory means for causing system 100 to perform various operations in accordance With the present invention as is further described herein. and 218d of FIG. 2B can come in at least tWo ?avors: generic and unique. A generic class name is one that is typically used by many different WindoWs and does not therefore, uniquely distinguish one WindoW from all others. Examples of generic class names include ‘MDIiClient’ (Multi-Document Interface Client) such as is shoWn at 217d. With GUI-type operating systems (OS’s) such as Microsoft Windows 3.1”‘ or Microsoft WindoWs95TM, or Microsoft WindoWs NTTM 4.0 the OS often temporarily stores data object speci?cations of executable or other understood that the OS can maintain a data structure Within 25 Other examples of commonly used, generic class names include: ScrollBar; Edit; MsoCommandBar (Microsoft softWare objects that are currently ‘open’ and immediately executable or otherWise accessible to the CPU 150. Of?ce menu bar); MsoCommandBarDock; WWB (WindoWs Work block); and WWC (WindoWs Work Container). Class Although not speci?cally shoWn in FIG. 2A, parts of system names such as ‘Menu BAR’ and ‘BUTTON’ or ‘BUTTONS’ memory 160 can be dynamically allocated for storing the (216d) are further examples of names that may be deemed data object speci?cations of open objects. The so-allocated generic. memory space may be de-allocated When the corresponding object closes. The de-allocated memory space can then be On the other hand, a unique class name such as the overWritten With neW information as demanded by system operations and actions of third party application programs. 35 ‘WordPerfect.7.32’ of region 214d usually distinguishes a given WindoW (e.g., 114) as belonging to a particular pro gram (e.g., Corel WordPerfect7.0TM for Win32 operating One of the data object speci?cations that the OS stores is a de?nition of Which open WindoW is a child of Which open systems) and/or as being the outermost frame of that appli parent. Whenever a neW WindoW is created, the OS usually assigns a unique, WindoW handle number to that WindoW. The OS handle number (e.g., the one stored respectively in 214a—218a) may be used to uniquely address a given WindoW. HoWever, OS handle numbers are often assigned randomly during each run of the operating system, and as a cation program (124). FIG. 2B illustrates an example of a WindoWs hierarchy chart 200 as such may be de?ned Within a given computer (e.g., 100 of FIG. 1). Where practical, like reference numer als in the “200” century series are used for elements of FIG. 2B that correspond to elements referenced by “100” century series numbers in FIG. 1. Accordingly, element 211 corre sponds to the desktop WindoW 111 of FIG. 1. Element 214 corresponds to the outermost program WindoW 114. Chart consequence, one cannot be sure that a given OS handle Will 45 element 214 is understood to be a child of parent element be used each time for a given WindoW. When a parent WindoW (e.g., 114) has more than one immediate children, it may or may not Wish to address those children (e.g., 115, 116, 117) individually, To this end, the 211 by virtue of the branch connection 213 Which extends from trunk line 212. It is understood that many other branches (not shoWn) and correspondingly attached sub parent WindoW may assign, locally-unique, control ID’s (e.g., A1, A2, A3) to its respective child WindoWs such as trees may emanate from trunk line 212. indicated in regions 215e—217e. Although illustrated as Similarly, chart elements 215, 216, 217 are understood to be hierarchical children of element 214 by virtue of the respective sub-trunk and branch connections Which extends from element 214. Furthermore, chart element 218 is under stood to be hierarchical child of container element 217 by virtue of the respective sub-trunk and branch connections Which extends from element 217. alphanumeric designations, control ID’s may come in a strictly numeric format. The WindoWs hierarchy structure 200 of a given program 55 may be scanned by manual or automatic means to determine Which of its WindoWs contains data that is Worth saving in case of a freeZe. For example the Highlight function of Microsoft’s Spy++ program may be manually deployed to Referring by Way of example to chart element 214 (the identify a correspondence betWeen an on-screen WindoW one representing the Word Process Outermost WindoW 114), such as 118 and the hierarchical chart element (e.g., 218) Which de?nes its hierarchical position Within the chart 200. In general, different programs have respective and differ it is seen that each chart element can be identi?ed by a variety of attributes, including, but generally not limited to: (a) an OS ‘handle’ 214a assigned to its corresponding WindoW by the OS, (b) a WindoW ‘caption’ ?eld 214b Which ent WindoWs hierarchy structures. It is up to the programmer to decide Which WindoWs should be children of What other shoW in the actual WindoW; (c) a parent WindoW (PW) WindoWs, What sequence they are opened up in, and Whether each given WindoW is of a generic or unique class. A handle 214c Which is the same as the OS handle of the database may be constructed for each of multiple, commer may be blank or ?lled and Whose contents do not necessarily 65 US 6,630,946 B2 11 12 cial programs to identify Where in the WindoWs hierarchy of each, there Will most likely be a WindoW that contains information that the end user Would generally consider vital. In the examples of FIGS. 1 and 2B, the immediate children of Parent A3 (117, 217) Will be the ones holding gram name of a just-revived program 124‘ and also matches With a navigation-path to-an-existing-WindoW found in the just-revived program 124‘; or that correlates (statistics Wise) With a navigation-path to-an-existing-WindoW found in a just-revived program 124‘ (of unanticipated name) such that such ‘vital’ data that a user Will most likely Want to save, ?rst and foremost, before saving other data that may be contained in other WindoWs of the just-revived program 124‘. It has been found that the simple sending of a CLOSE message to the WindoW (e.g., 118) Which directly holds Work product 10 information (e.g., typed text, spreadsheet records, draWing vectors, etc.) usually causes that WindoW to nonvolatily save its oWn Work product information to disk (or elseWhere) and to thereafter close such that other objects cannot corrupt its the found navigation path de?nition provides a rough best guess pro?le for the locating a vital data-containing WindoW in the domain of the just-revived program 124‘. This can be explained better by considering an example of hoW a neW record (ID RECORD) 330 for distinctly identi fying a vital data-containing WindoW is added to the data base 310. At step 340, a neW application program is run (executed and exercised, preferably by a skilled artisan) for the purpose of de?ning one or more navigation paths to its contents. On the other hand, if a CLOSE message is sent to 15 vital data-containing WindoWs. At step 342, a spying pro a WindoW (e.g., 117) Which indirectly holds Work product information, the Work product information that is indirectly gram such as Spy++TM is used for detecting the presence of different WindoWs Within the running program (340) and for tracing the parent/child hierarchies that form Within the contained therein Will generally not be saved, and Worse yet, the ability of the immediate data-holding WindoWs (e.g., 118, 119) to thereafter perform a SAVE operation upon running program. At step 344, dummy or actual vital data is generated through the use of the running program (340) and the spying receipt of a CLOSE command may be corrupted. It is therefore desirable, in accordance With the invention, program (342) is used to identify the location of a to precisely identify the one or more WindoWs of a just corresponding, vital data-containing WindoW (e.g., 328) revived application program (e.g., 124‘) that immediately Within the parent/child hierarchy chart (e.g., 325) of the running program (340). The spying program (342) is further contain vital data and to issue one or both of a SAVE and 25 used to identify attributes of the vital data-containing Win CLOSE command messages to such WindoWs. For some doW (e.g., 328) and attributes of its parents or grandparents (e.g., 324) that Will help to distinctively isolate or uniquely off-the-shelf, commercial programs, such as Corel WordPerfect7/8TM, the step of identifying the WindoWs that immediately contain vital data is relatively simple because identify the vital data-containing WindoW based on such attributes. It is to be understood that above steps 342, 344 these ?les have a unique class name (e. g., WPiDociFrame such as shoWn at 218a) HoWever, for other application programs, such as Microsoft Word 6/7/8TM, the WindoWs and beloW step 345 are preferably to be carried out by a skilled artisan Who understands the internal and hierarchical nature of multi-WindoW, composite objects, and understands that immediately contain vital data have generic class names (e.g., WWB) and Worse yet, the outer container WindoWs (e.g., 117) that contain such vital-holding, inner WindoWs the difference betWeen rules that distinctively isolate Win 35 by WindoWs of interest (but are also satis?ed by WindoWs Whose contents are not Worthy of being saved.) The skilled also have a same or other generic class name. This factor makes it dif?cult to automatically locate the correct Win doWs of an arbitrary, just-revived program 124‘ that contains vital data and should therefore be ?rst commanded to SAVE and CLOSE. FIG. 3 illustrates a system 300 in accordance With the invention for use in identifying the appropriate WindoWs that artisan is responsible for identifying speci?c attributes of the spied-upon WindoWs that can be used for distinctively isolating WindoWs of interest. The WindoW-related attributes that the inventors have found to be most useful in this endeavor, are ?rst and foremost, the class (e.g., 314a) of each child or parent and secondly, the sequence in Which such class assignments contain vital data that a user most likely Wants to save after an apparent freeZe. A pro?ling database 310 is built up in accordance With the invention for helping to identify the doWs of interest as opposed to rules that are merely satis?ed 45 appear as one traces doWn the WindoWs hierarchy chart vital data-containing WindoWs of both popular (Well knoWn) (200) from outermost frame (214) to the WindoW (e.g., 218) and commercial application programs as Well as for making intelligent guesses on Which WindoWs of obscure application that immediately contains the vital data. Another attribute programs are most likely to contain the vital data that the for such ferreting out of the vital data-containing WindoW, is the WindoW caption attribute (214b). For some speci?c types of application programs (e.g., Internet broWsers), the control ID (2146) that is assigned in a unique Way to certain child that may be used alone or in combination With WindoW class user Would most likely Want to save after an apparent freeZe. The database 310 may be formed as part of the general registry of the computer system or by other convenient means. As seen, a ?rst searchable part 311 of the database is dedicated to pre-existing and Well-knoWn commercial appli 55 cation programs such as various versions of Microsoft WordTM, Microsoft ExcelTM and various versions of other popular Word processing and spreadsheet programs. A sec ond searchable part 312 of the database is dedicated to WindoWs may be useful for ferreting out such child Win doWs. Also, it may be valuable to pay attention to hierarchy patterns in Which a WindoW of interest is alWays accompa nied by another WindoW Whose data is not of interest. It may be WorthWhile to de?ne parallel satisfaction rules that isolate WindoWs Whose data Will not be saved, so that WindoWs of pre-existing, but less Well-knoWn, commercial application interest can be better isolated. Assume for purposes of this programs. A third searchable part 335 of the database is example only that, in the hierarchy tree shoWn at 325, item dedicated for adding on, navigation path de?nitions for locating the vital data-containing WindoWs of afterWards 329 is a WindoW of interest While item 328 is a WindoW Whose data is not of interest. Assume further that no direct created or later found, application programs. The various parts of the database 310 are searchable by a rule can be devised for isolating target WindoW 329 (because 65 for example, it is an immediate child of outermost WindoW machine-implemented search engine for ?nding a naviga 324 and other such immediate children all have a same set tion path de?nition that either matches With both the pro of nondistinguishing attributes.) Assume yet further that US 6,630,946 B2 13 14 target WindoW 329 can be nonetheless isolated by the fact relaxed rule being PGMiNAME=“*”) in counterbalance to that it does not have a child of its oWn like WindoW 328. A parallel satisfaction rule can then be devised to say that not other Words, if the PGMiNAME is very tightly-de?ned a tightening of the NAViPATH rules and vice versa. In only does the target WindoW 329 have to satisfy a certain navigation rule to its position in the hierarchy, but also that there must simultaneous satisfaction (affirmative or negative) of a parallel navigation to another WindoW, such as non-target WindoW 328. (e.g., PGMiNAME=“WORDPERFECT.7.32.05”), then navigation path rules can be correspondingly loosened (e. g., NAViPATH=*/MDI*/*). If the navigation path rules are very tightly-de?ned (e.g., NAViPATH=“*/MDICLIENT/ WPDOC.7.32”), then the PGMiNAME satisfaction rule can be loosened in comparison because it is unlikely that One or both of manual and automated methods may be used for generating a set of rules that Will enable best-guess, and automated identi?cation of vital data-containing Win another application program Would, by happenstance, sat isfy such tight NAViPATH rules. doWs. Step 345 represents such methods for generating WindoW-identi?cation rules that Will enable best-guess, automated identi?cation of vital data-containing WindoWs. 330) are ordered alphabetically to simplify searching As explained above, it Will often be necessary to have a skilled artisan involved, namely one Who understands the concepts of WindoW hierarchies and of the difference In one embodiment, the rules records (such as ID record 15 through them. In an alternate or complementary embodiment, the rules records (such as ID record 330) are ordered in accordance With likelihood of occurrence so that the records (311) of the more popular, commercial products betWeen distinguishing and non-distinguishing rules for are searched ?rst for satisfaction and records (335) for obscure applications, including those Whose names cannot be pre-anticipated are searched last. If the just-revived navigating to a target WindoW. The manual and/or automated methods of step 345 should establish rules Which automati cally exclude application WindoWs that are least likely to program 124‘ is such an obscure program Whose name contain vital data and Which automatically include applica and/or WindoWs hierarchy structure cannot be pre tion WindoWs that are more likely to contain vital data. anticipated, the hope is that the obscure program (335) Step 347 represents the adding or recording of a neW database record 349 into the database 310, Where the added record 349 de?nes the WindoW-distinguishing exclusion 25 CAPTION pattern have already been captured in the data base. It has been found, for example, that the general rule: PGMiNAME=“*” and NAViPATH=“*/MDICLIENT/*” is quite useful for correctly identifying the vital data containing WindoWs of many obscure application programs. and/or inclusion rules (direct and/or parallel) that is/are usable by a machine for automatically and distinguishingly identifying the WindoW(s) that Was/Were manually identi?ed in step 344. After the neW ID record is added (349), looping step 348 may be folloWed for identifying a next, one or more target WindoWs that store vital data Within the running application (340) or Within a next-to-be categorized, appli cation program. Amore speci?c example of WindoW-identi?cation rules is shoWn in boxed illustration 350. The boxed rule (350) may conforms to a WindoWs hierarchy and CLASS/CAPTION pattern of some other obscure or more popular (312) appli cation program Whose WindoWs hierarchy and CLASS/ 35 It is sometimes useful to specify a Save-And-Close (SAC) message stream that is to be sent to a vital data-containing WindoW. The illustrated SACiMSSG ?eld 355 of FIG. 3 may be used to store the Save-And-Close message stream that is to be used in response to satisfaction of one or both be read as folloWs: The identi?ed WindoW is likely to contain vital data IF the name of the just-revived application pro of the PGMiNAME and NAViPATH rules. In one embodiment, if ?eld 355 is empty or not present, the default gram (124‘) satis?es a ?rst search query, namely, PGMi NAME=“WORDX.*32”, Where the asterisk inside the WindoWs messages, “WMiCLOSE” and “WMi SAC message stream includes one or both of the Microsoft ENDSESSION”. search query represents a multi-character Wild card (or more speci?cally, an arbitrary string of none, one or many It is sometimes useful to specify a Save-OK (SOK) message stream that is to be sent to a save-blocking dialog characters), AND IF the navigation path to the WindoW is such that the outermost application frame on the desktop satis?es the second search query: OUTERiCLASS= 45 “WWB”, AND the next successive hierarchy level parent (LeveliA) satis?es the more complex search query: doW. The illustrated SOKiMSSG ?eld 357 of FIG. 3 may be used to store the Save-OK message stream that is to be {LEVELiA CLASS=“MDI*” AND LEVELiA used in response to such save-blocking dialogs if there is a preceding satisfaction of one or both of the PGMiNAME and NAViPATH rules. In one embodiment, if ?eld 357 is CAPTION=“*MENU*}, AND the next successive hierar chy level WindoW (LeveliB) satis?es the don’t care condi tion: Attribute=*, AND the next successive hierarchy level, empty or not present, the default SOK message stream includes “ENTERiKEY” Which represents a virtual press Which is the targeted child WindoW (e.g., LeveliC) satis?es ing of the keyboard ENTER key by the user. For some application programs, it has been found that the SOK the search query: {LEVELiC CLASS=“WPDOC?.32”} Where the question mark is a single character Wild card. See also the How chart of FIG. 5 Which is described beloW. The illustrated rule 350 is of course, merely an example and therefore conveys the contemplation herein of many variations, including but not limited to: (a) not de?ning the program name (PGMiNAME) or alloWing the PGMi NAME quali?er to be the multi-character Wild card (b) 55 message stream (357) can be the same as the SAC message stream (355). In other Words, if a “WMiCLOSE” message or another such SAC message or message stream is sent to the save-blocking dialog, the save-blocking dialog interprets the response With such a SAC-like message as a con?rma tion that the controlling user or program Wishes to continue With the Save-And-Close operation, and as a consequence, additionally or alternatively using further Boolean operators the save-blocking dialog closes itself and lets the SAC operation continue unabated. such as NOT and OR to respectively exclude and include various navigation sub-paths; and (c) using attributes other than CLASS and CAPTION for de?ning satisfaction con ditions (e.g., CONTROLiID=“B.2”). In general, the rule for satisfaction of the PGMiNAME query can be relaxed (made easier to satisfy, the ultimately that is put up by a vital data-containing WindoW during the Save-And-Close operations of the vital data-containing Win 65 The rules record that is represented in FIG. 3 at location 315 is shoWn in pictorial form to graphically demonstrate the idea that multiple WindoWs at a given hierarchy level (e.g., LeveliC) may satisfy a corresponding search query. US 6,630,946 B2 15 16 Thus in illustrated record 315, the satisfying navigation path If the user instead clicks on the ANTI-FREEZE starts at outermost frame 314, excludes all the leveliB pushbutton, then action path 452 is folloWed, and one or more revival techniques 462 are applied to the correspond WindoWs, and ?nally isolates a distinguished subset, 318 of plural WindoWs in leveliC as being the best candidates for containing vital data. By contrast, the rules record that is graphically represented at 325 simultaneously isolates both ing application program 440. (The revival techniques 462 can include those of the above-cited, U.S. Ser. No. 08/938, 204.) After the revival attempts 462 are carried out, full control is returned to the user. The user is then alloWed to a leveliB WindoW 329 and a leveliC WindoW 328 as being the best candidates for containing vital data for its respective application program. Those skilled in the art Will realiZe of course that a complex, cross-level rule such as represented at 325 may be replaced With tWo ID records that have simpler distinguishing rules (one for 328 and another for 329), each for isolating candidates in a single and respective hierarchy level. Many other variations of this type for formulating the candidate isolating rules and/or the candidates-selecting knowledge database, Will of course 10 the possibility that some or all of the SAVE (or SAVEiAS . . . , etc.) functions of the just-revived program 15 become apparent to those skilled in the art in vieW of the present disclosure. Step 360 represents a machine-implemented process Which uses the records 311—335 of database 310 to make 20 or more WindoWs of a just-revived program (124‘) Will most the FILE drop doWn menu of the outer WindoW 114 is no de?ned by steps 452—462—468 is acceptable if the human user is calm, skilled and understands the urgency of manu 25 tions according to a sequence Which starts With most-likely candidates and trails off With least-likely candidates so that, ally saving as much Work product as possible; and also if the application program 440‘ is stable enough after revival attempt 462 to enable the calm and skilled user to manually save his or her Work product. If the user had instead clicked on the VITAL-SAVE if the just-revived program 124‘ experiences further crashes or other freeZes during the save-vital-data operations, at least the more likely candidates Will have had a better chance of 440‘/124‘ may no longer be functioning either properly or at all. For example the FILE drop doWn menu of the outer WindoW 114 may no longer be Working. A novice user may not realiZe this and may keep typing under the mistaken belief that the resuscitation efforts 462 have brought the just-revived program 440‘/124‘ back to full health. Then in a panicked surprise, the novice user may later discover that longer Working. This can result in poor choices by the user of What to do next. The less-automated, anti-freeZe approach intelligent identi?cation guesses or choices as to Which one likely contain vital-data and What the order of likelihood is for the plural WindoWs of a given, just-revived program (124‘). It may be desirable to try the save-vital-data opera manually attempt to save his or her unsaved Work product by using functions of the just-revived program 440‘/124‘ or by other user-selected means. This option is indicated by box 468. In using the manual-save approach, the user is risking 30 being saved before the multi-crashing program dies for good pushbutton of dialog box 450, then action path 453 Would have been folloWed. One or more revival techniques 463 are (cannot be revived anymore). then automatically applied to the corresponding application FIG. 4 provides a schematic diagram of a system 400 for so-utiliZing a best-guess database 410 or the like. Applica tion program 440 is one of plural, and preemptively multi tasked programs running under an appropriate OS. At time program 440. The revival attempts 463 are generally the same as those applied in step 462 but they can be of a less 35 point 441, the user detects a behavior or lack of behavior that cause the user to perceive program 440 as having become froZen. (This perception can be right or Wrong as explained above.) At time point 442 and in response, the user invokes a defreeZing subroutine that puts up dialog box 450. and automated step 465. After the revival attempts 463 are carried out, and as 40 indicated immediately above, control is maintained by the machine and passed on to a vital-save program 465. Inter Alternatively, at time point 443, a guard program (e.g., Symantec CrashGuardTM) that had been running in the cepting actions may be taken by the vital-save program 465 background, detects a behavior or a lack of behavior (e.g., not responding to messages) in application program 440. aggressive (and of less potentially, application destabiliZing) nature given that vital data-containing Win doWs Will be automatically saved and closed in subsequent, 45 This causes the guard program to perceive program 440 as having become froZen or having encountered a fatal error. At time point 444 and in response to detection step 443, the guard program automatically invokes the defreeZing sub to prevent the user from gaining control over the just revived program (440‘/124‘) until after the vital-save pro gram 465 has had an opportunity to automatically save the contents of, and/or close as many vital data-containing WindoWs of the just-revived program (440‘/124‘) as the vital-save program 465 can con?dently identify. One of the Ways in Which the vital-save program 465 tries to prevent the user from gaining control, is by detecting dialog WindoWs routine that puts up dialog box 450 on the user’s display. The illustrated dialog box 450 is shoWn by Way of that are throWn up by the just-revived program 440‘/124‘ example to include three pushbuttons, respectively denoted (such as “Are you sure you Want to close this document? as TERMINATE, ANTI-FREEZE and VITAL-SAVE. Press ENTER or YES if true.”) and by automatically select (Other terms could be used, and the VITAL-SAVE button or its equivalent could be presented With feWer or more of the other user-choice buttons. The unfreeZe program may change the numbers and types of other buttons that are displayed in box 450 based on the context and environment under Which the unfreeZe program is asked to display dialog ing the correct option so as to alloW WindoW closure to 55 complete unabated. Item 357 (SOKiMSSG) of FIG. 3 de?nes the correct option for the given situation. As explained above, if ?eld 357 is empty or not present, the 60 default SOK message stream Will typically include the “ENTERiKEY” message or its equivalent to thereby de?ne a virtual pressing of the keyboard ENTER key by the user. user elects to click on the TERMINATE pushbutton, the user 65 That typically selects the preferential default option of the throWn-up dialog box that is noW blocking completion of the save-and-close operation for the vital data-containing Win doW. The throWn-up dialog box then closes and thereby lets the save-and-close operation continue toWards completion. Will be skipping the step of saving Work product that has not yet been saved and Will be risking the loss of such data. The automated process of identifying Which WindoWs in the just-revived program 440‘/124‘ contain vital data, uses box 450.) If the user clicks on the TERMINATE pushbutton, then action path 451 is folloWed, and the corresponding applica tion program 440 (including all its concurrent threads) is automatically terminated by the OS. Because of this, if the US 6,630,946 B2 17 18 database 410 as indicated by connection 464. In one embodiment, database 410 of FIG. 4 is substantially the WindoWs95/98TM, and thereafter record the name of, and shut doWn the main program by issuing to the main same as database 310 of FIG. 3. The vital-save process may outer WindoW (e. g., 114/214) of the program (440‘/ 124‘) include one or more of the following steps (1)—(10): one or more command messages such as (in preferred (1) Try to identify the name of the just-revived program 440/124‘, and if identi?ed, search the database 410 and order): WMiCLOSE and WMiQUIT. Even if the WMiCLOSE message does not Work, the WMiQUIT message should at least force the program to quit its main message loop. Thereafter, if neither of these steps causes the program (440‘/124‘) to shut doWn cleanly, try to locate Within database 410, a rules record Whose PGMiNAME satisfaction rule most tightly conforms With the identi?ed, program name; (2) If the PGMiNAME identi?cation step (1) fails, 10 search the database 410 and try to locate Within data base 410, a rules record Whose NAViPATH satisfac forcibly terminate the froZen-and-afterWards-revived program (440‘/124‘); tion rules most tightly conform With one or more to-WindoW navigation paths found Within the just revived program 440/124‘; (3) If the NAViPATH identi?cation step (2) fails, search 15 the database 410 and try to locate Within database 410, steps of to-WindoW navigation paths found Within the just FIG. 5 provides a How chart of a ?rst identi?cation revived program 440/124‘ such that the located rules record (e.g., NAViPATH=“*/MDICLIENT/*”) de?nes a general ‘style’ for WindoWs found Within the just-revived program 440/124‘; 25 revived program; (5) Using the best guess provided by any one of steps records are available. In one embodiment, step 520 folloWs While in an alternate embodiment, bypass path 525 is taken. In step 520, the by one of steps (1)—(3) for causing that data-containing WindoW to itself save its oWn data and thereafter, optionally shut itself doWn as cleanly as possible (one 35 subsequently addressed WindoWs); gation path criteria rule (NAViPATH) that applies to the current parent/child hierarchy level is fetched. Initially the other message that needs to be responded to in order to level is that of the outermost WindoW (114/214), but as Will be seen in step 565, the current level can be incremented to keep the save-and-shut-doWn process moving forWard 45 At subsequent step 550, a current parent/child hierarchy level in the WindoWs chart of the just-revived program 440‘/124‘ is scanned to ?nd a next WindoW Within that part of the chart Whose attributes satisfy the fetched navigation path criteria rule (NAViPATH) for that current level. If there is no, next such criteria-satisfying WindoW, path 555 is folloWed to step 557, Where current tree search tracking the continued carrying out of the save-and-shut-doWn controls are updated to indicate this level has been exhausted 55 save and shut doWn operation, a further freeZe or crash occurs, automatically detect that condition and auto so as to continue the carrying out of the save-and-shut doWn process for the corresponding, vital data that has just been found is deemed to be a good candidate for being a vital data-containing WindoW. At step 570, the OS handle (218a) of the matching WindoW is output as an containing, WindoW; (8) Repeat steps (5)—(7) until there are no more vital data-containing WindoWs left to instruct to save-and (9) Wait for program status to sWitch to idle by, for example, using the WaitForInputIdle function of for the current tree branch that is being investigated. If instead, a next such criteria-satisfying WindoW is found, path 552 is folloWed to test step 560. In test step 560, it is determined Whether the matching child WindoW corresponds to the last entry in the navigation path criteria rule (end of NAViPATH). If the ansWer is YES (569), then the WindoW matically attempt to again revive the re-froZen program shut-themselves-doWn; deeper levels, such as LeveliA child, IJeveliB child, LeveliC child and so on. instructing the user to pick the option that in the process-abating dialog box that is least likely to block process for the vital data-containing WindoW; (7) If during the execution of each WindoW’s self-invoked machine-implemented method 500 tests for satisfaction of the PGMiNAME search criteria. Path 529 is taken back to step 511 if the PGMiNAME search criteria is not satis?ed Path 522 (OK) is taken to subsequent step 530 if the PGMiNAME search criteria is satis?ed. At folloWing step 530, a level-tracking pointer starts by pointing to the parent/child hierarchy of the outermost WindoW (114/214) of the just-revived program 124‘. At subsequent step 540, that portion of the current navi (6) During the execution of each WindoW-invoked save and shut doWn operation, optionally monitor the Win doWs environment of the desktop to see if the saving/ shutting-doWn WindoW (the one containing What is presumed to be vital data) puts up any dialog box or unabated. If such a process-abating dialog box or other message is detected, to the extent possible on an automatic basis, ansWer the dialog box or other mes sage in a manner Which Will keep the save-and-shut doWn process moving forWard unabated. Where such automatic response to the process-abating dialog box or other message is not possible, put up a dialog box process 500 for identifying those WindoWs of a just-revived program 440‘/124‘ that probably contain vital data. Initial entry is made at step 501. At subsequent step 510, the method points to the top or other starting point of the ID records database 310/410. At folloWing step 511, the method selects a next ID record (e.g., 350) from Within the database. If there is none, an exit is made by Way of path 519 With an indication that no more (1)—(3), and as soon as possible after the de-suspend, send messages (e.g., WMiCLOSE) or instructions to the vital data-containing WindoW that is best selected reason for this being so that the already-saved WindoW does not block or interfere With savings operations of (10) Wait for the program termination to complete and thereafter, either automatically or after permission is manually granted by the user, relaunch a fresh (not corrupted) copy of the froZen-and-afterWards-revived program, and re-load into that fresh copy of the program, the data that had been saved by the process of a generaliZed or obscure rules record Whose satisfaction rules conform in a relatively tight Way With one or more (4) De-suspend the just-revived program 440/124‘ so that the operating system begins giving task time to the use the TerminateProcess function of the OS to more identi?cation of such a good candidate. Of course, other 65 means for uniquely identifying the good candidate WindoW may be used alternatively. The result Which exits out from step 570 may feed into a list-making routine Which compiles US 6,630,946 B2 19 20 a list of good candidates, Where that list may be further Using the rule list of the ID record 350 shoWn in FIG. 3, sorted for distinguishing betWeen candidates that are more for example, the folloWing parameters Would be passed to FindMatchingChild: (a) the OS handle for the desktop likely or less likely to contain vital data. Alternatively, the result that ?oWs out With the EXIT from step 570 may be immediately used for sending a Save-And-Close (SAC) message stream (e.g., 355) to the matching WindoW of the WindoW, and (b) the NAViPATH rules: {Class=“WWB”}/ {Class=“MDI*” & Caption=“ * MENU*”}/{ Child=* }/ {Class=“WPDOC?.32”}. The FindMatchingChild function searches each child of the desktop until it ?nds one of class “WWB”, the outermost just-revived program 440‘/124‘. If the ansWer test step 560 is NO (562), then the WindoW that has just been found is deemed to be merely a possible parent of a possible good candidate. The actual child Win doW that is being sought is deeper into the search tree, and as such, step 565 increments the level tracking control to go to the next deeper level. If the current level had been the outermost frame (Leveli0), then the next deeper level is LeveliA. If the current level had been LeveliA then the next deeper level is LeveliB, and so forth. Control is thereafter given to step 540 and the loop continues until a matching WindoW that meets the full criteria of the naviga 10 15 FindMatchingChild( viWindoW, virules ) tion path rule (from front to end of NAViPATH) is found; FOR each child of VfWll’ldOW do or the search tree branch is exhausted and, as a result, the { search should move on to a neW branch. As long as exploration of a given level is not exhausted, third entry point 503 may be used to repeatedly enter the loop de?ned by steps 550—560—540 and to search for more child WindoWs that satisfy the full criteria of the navigation path rule. Once that section of the searchable tree is exhausted, the search recursively steps back up the tree to IF (child satis?es ?rst rule in virules) then do { IF next rule exists in virules then FindMatchingChild( child, next rule in virules ELSE 25 } } //End of FindMatchingChild been reached, then control passes along path 581 back to step 540. On the other hand, if the top of the tree has been reached, path 583 returns control back to step 511 for the fetching of a next ID record. Alternatively, path 583 can be an exit step. The next-higher level of softWare can then 35 As can be seen, the FindMatchingChild function recursively shrinks the siZe of the trailing part of the rules until there is none left. At that point it is knoWn that the found child WindoW satis?ed all the criteria in the NAViPATH rules. The match is appended to the global list at that time. Contents of the global list may be sorted as desired after Wards to determine Which match should ?rst be instructed to itself execute the Save-And-Close (SAC) operation (per message 355). data-containing WindoW is given by the beloW pseudo-coded function, “FindMatchingChild”. The function, “FindMatchingChild”, accepts tWo parameters: 1) a particu FIGS. 6A—6B combine to de?ne a How chart 600 depict ing broader aspects of a machine-implemented, vital-save operation in accordance With the invention. Entry may be made at step 601. If bypass path 605 is not optionally taken, lar branch-starting WindoW Whose descendants are to be searched; and 2) a list of satisfaction rules that are to be satis?ed by the matching descendants. It is assumed that a then at step 610 an attempt is made to identify the name of the just-revived program 440‘/124‘. In some instances this is global list of matches is being compiled for storing each of the successful matches. When the call to FindMatchingChild child satis?ed all rules, ADD it to global list of matches } ?nd the next unexplored branch by passing through step 559 (Decrement Hierarchy Level). If the top of the tree has not selectively re-enter the illustrated loops by Way of second entry point 502, Which feeds into step 511. Asecond method for performing identi?cation of the vital frame. It then calls itself recursively, passing the handle for the matched child and the trailing-remainder of the rule list to its called self. For each pre-matched child of that WindoW, the recursive call applies the next trailing part of the rule and calls itself again. Any time the calls-to-self recurse deeply enough to satisfy the last criteria in the rules list, the child is stored aWay in the global list of matches. 45 a relatively trivial task and in some instances it may not a match by checking the siZe of the global list to see that it is either no longer empty or has groWn. Work. Success depends on hoW Well the just-revived pro gram 440‘/124‘ conforms to self-identi?cation protocols and hoW the crashed, or otherWise froZen thread ties in With the The beloW pseudo-code for the FindMatchingChild func tion begins at a point that corresponds roughly to step 530 of FIG. 5. Some particular ID record has been selected and passes control to step 620. If the identi?cation attempt succeeds, subsequent step 611 ?lters out from the database completes, a test may be run to see if it succeeded in ?nding its rule list has been obtained. The FindMatchingChild function can be employed in at least one of tWo Ways: 1) by passing it the programs outermost WindoW and a list of matching rules, or 2) by main program. If the identi?cation attempt fails, path 619 310/410, those ID records (e.g., 350) Whose PGMiNAME criteria are satis?ed by the identi?cation found in step 610, and these ?ltered out records are passed to step 620. 55 passing it the desktop WindoW and requiring the ?rst rule to ?nd the program’s outermost WindoW (Which WindoW is a child of the desktop). These tWo methods should yield generally equivalent results. The second method provides a slightly greater amount of ?exibility in that the name of the just-revived program (124‘) is not alWays identi?able by automatic means, but the just-revived program can be none theless identi?ed as a child of the desktop (111) that has certain WindoW attributes. The second approach also sim pli?es the process by integrating the step of ?nding the outermost grandparent WindoW into the recursive procedure for searching for all the child document Windows. 65 Step 620 may be arrived at from successful completion of ?ltering step 611, or by Way of failure path 619 or by Way of bypass path 605. The Whole or subset of database 310/410 that is passed to step 620 is searched for rules records Whose NAViPATH criteria most tightly conform With navigation paths to WindoWs actually found in the just-revived program 440‘/124‘. The algorithm of steps 530—570 of FIG. 5, or the above-speci?ed recursive algorithm may be used to locate such tightly conforming WindoWs. If the search or plural searches of step 620 is/are successful, the search results are passed by Way of path 621 to step 640. If the tight search(es) of step 620 is/are not successful, control passes to step 630. Here a more relaxed search is