Ititially this appeared very ramdom. I have learned to cook this down (From what I mentioned in Discourse thread “Access violation Crash”, Oct-2021>Sep-2022). That thread seemed then to be mostly MAC centric when I tagged in my Windows situation. I had hoped that the addition would have been helpful for the developers to diagnose the issue. Now this, Windows centric, is a more compact and a bit easier to follow, I hope?
Multiple open databases have different characteristics (starting in Version 8) - First opened database is what I call Dominant, all others (up to 3 more) are Subordinate, I generally open 4 but 2 is enough to demonstrate the problem. The visable difference between dominant and subordinate is where the icon(s) goes when they are iconized. I mostly run on Windows 7 system. These databases are all uplifted from a Version 7 form at least at each new release before doing this testing.
Process start:
Open 4 databases - A/B/C/D. Iconize A and all databases go into a taskbar Icon (that is any displayed or iconized Subordinate databases go from the desktop into the single taskbar icon). Then restore A (one click and all databases restore to the desktop).
Close database A (either File > Close or the upper right X) and select either Backup or Skip Backup (no difference). B now inherits the dominant database status. Iconize B (all remaining follow) and then restore from the taskbar. Check for an all-white window, that was formally A, but now just residue. X it out and there is an Unexpected Error Acc-Vio pop-up reporting window. Send the Error. This white shell can be moved around on the screen and even iconized (as a Subordinate) but not deleted.
Second Iteration:
Iconize Database B > (all into the taskbar). Restore B and all 3 databases are displayed along with the still empty white shell for A. X out B and C inherits the Dominant status. Iconize C and restore C, on the Restore of C and all remaining databases show up and among the remaining windows there may be another white window (2 databases and 2 white shells). X the white shell and it tells you ‘I already reported this, restart RootsMagic’.
Rinse and repeat:
Each of the ‘restored windows’ is a white, completely blank window where one of the eliminated databases used to reside. Depending on where we are in the close up cycles there can be up to 3 white blanks. These white windows can be iconized into the desktop and restored (still white) moved around on the screen. Placement on the screen seems to imply which former database occupied these remnants.
Done:
Early-on (in Preview 8 testing) these errors used to provide some address details of the AV, not today (pre-9.0.4). Now there is a two button pop-up window, Send Error Report and Don’t Send. Very early on during the Preview testing I provided screen shots and reported them on the tracking system that was in vogue at the time.
BTW - Two Windoze 7 and 1 Windoze 10 system in my house do this. All these systems were tested during 8.2.5 but now only one system tested, same as the one all through the Community Preview, (release V8 and released V9) with each new release.
Update - upon the release of RM9 things are identical through 9.0.3.0.
In addition I have tried this with RM-To-Go in 9.0.2.0 and it fails in the same way.
Update - no correction in 9.0.4.0 but there is a change. It is no longer an ‘Unexpected Error - Access Violation’ box that pops, only an ‘Access Violation’ (no Send Error Report button which prompted the question) box which has gory address and data details in it. This new box also does not eliminate the blank white window but each attempt to close it (X) it redisplays the Access Violation box. Now a new wrinkle appeared in the reactions to the process. The closing of Database A. (first of 4) still follows the pattern above but now the new Access Violation box is not tied into that blank white window so the window can be moved or iconized while the AVIO box stays in place or on screen. It now appears each white blank can pop the ACVIO box where before it said ‘already reported that’ for B and C.