I see in 9.0.4.0 the access violation error no longer has a Unexpected Error button box pop (which includes a ‘Send Error Report’ button) but just the gory details of the Access violation and an OK button. Does this still get reported to RM Central or does it mean I should report the gory details as they occur?
\s\Rick
AVs have become quite rare so best to report to support as they will probably be happily unaware of it.
( as kfunk said the other day–) I assume @ Rooty that this is sarcasm and my sarcasm meter is broken 
@fahumm – support is basically unaware of any access violations unless you do report them— awhile back ( on RM 8), I reported an error to support and asked if they could access the the error report sent in the previous Sunday as my access violations were random - so couldn’t answer her questions.
Supports response was
“I am sorry, but the error messages go to our development department anonymously. I have no way of finding out which one would be yours and I could not read they anyway. They are sent in computer language”
When you contact support, they want to know the exact step you took to get this error and also need to know what the error is, access violation, out of memory or out of range, SQLite with a number at end. like SQLite11, malformed file— they also want a backup of your file …
I couldn’t do any of that as I clicked out of the error to fast and then made a backup of the other database I had open ( the 1st one I opened) and the database with the error disappeared…
SO what were you doing before the access violations?
RE: they will probably be happily unaware of it.
I don’t think so!
I have reported this failure since V7.9.56 (Community Preview of RM V8) with every new release of V7.9.X using what ever method they had in vogue at the time. All the reporting was open loop so I don’t know if anyone ever saw them (someone slipped in text to my initial report, anonymously, that says they go to development anonymously - the 9.0.3 or the 9.0.4 behavior ).
Now let me put on my ‘glass is half full’ hat. They changed the AVio trap in V9.0.4 to report all of them, to get an accurate count of the problem (eliminate people who might not click the ‘send error report’ button).
… and the ‘glass is half empty’ hat. They got tired of my reports with every new version from 8.0 on and changed it so that they did not get any more.
\s\Rick
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.
I followed what you posted and EXACT same thing happened to me–so @rzamor1 --how abt some input on this as I have had the white windows pop up randomly since RM 8…
I normally have several databases open and will be working in one and, look up and see that one of the databases in the back has turned white-- I have NOT closed any of the databases and I don’t normal get an error message on them as I don’t try to close that white database BUT do go thru the process of closing down all the files as I know that something is NOT right-- I also do NOT get any others turn white as I am closing the files-- the one white box will disappear USUALLY after I close the last file but sometimes before…
I have Windows 11
If you don’t minimize the databases to the task bar do you still get a white database screen at times?
Until the dominant window gets minimized (task bar), restored, then deleted (and the graduated window gets minimized and restored) I have not see blank white windows.
If I open A/B/C/D as before and minimize B and C (desktop) then restore them then minimize A (task bar) and restore it, I do not see blank white windows.
If I then delete A, minimize D to the task bar and restore it there is a blank white window where A had once been.
So it seems that only the dominant window produces the blank white window residue and only after the next dominant window has been minimized (task bar) and restored.
I just stumbled onto something doing these exercises, not sure if it is significant or not. At any time if I hover on the icon in the task bar it always pops a balloon showing database A name/path even when A has been closed.
\s\Rick