Registry Cleaner in 1.5.2.342 -- "Failed to backup ...

tullik

Registry Cleaner in 1.5.2.342 -- "Failed to backup ..." messages

This problem possibly was not introduced by 1.5.2.342. Some recent posts have reported the same symptoms with 1.5.2.338 ...

Problem situation:

I usually use the Remove button instead of the Fix button. This time, I used the Fix button to test a fix for a GUI problem with the Fix results information pop-up.

Results:

-- There were 12 items on the list (6 HKCU/HKUS twins).

-- I got 6 "Failed to backup ..." messages.

-- All the messages referred to the HKUS sibling in each pair of twins..

-- All 12 items were "File or directory "path" does not exist" errors.

-- All 12 items were under the second UserAssist\...\Count key (possibly irrelevant).

-- the User Assist items are not encrypted.

-- The Fix results pop-up said 12 items were fixed.

-- The backup contained the 6 HKCU twins.

-- Restore put back the original 12 error lines.

-- A rescan showed those 12 lines plus 2 more that were not there before ...

-- The only things wrong in the above scenario are the error messages and the two additional lines ...

-- No harm done -- backup was sufficient to restore the registry state and the two additional lines could be removed ...

Probable cause:

RC got an API return code when it asked to backup/remove the second sibling of each twin pair. Since removing (or restoring) the first sibling removes (or restores) the second at same time, the API request could not be satisfied.

Additional tests:

Restoring and repeating the test, but using the Remove button, produced no messages.

Restoring and using the Custom fix... feature produced no error messages -- but all 12 "best possible solutions" pointed to the same path\filename, which also did not exist!. The backup contained the 12 items on the RC list, but the items did not change in the registry -- an immediate rescan still showed the original twelve lines plus two new lines for the "best possible solution." That solution was in Filecache.dat. After removing the two new lines and flushing the cache, I repeated the original scenario -- there were no error messages -- but the two new lines were reintroduced into the registry (cache must still be in memory). Fix results still said 12 items were fixed. Backup was OK. I restored the 12 errors, ended PT and started PT, let cache update happen, and repeated the original scenario. The same error messages occurred but the "Fix" actually found the files which I had moved much earlier.

Conclusions:

The error messages are a bug.

Most (all?) the other behavior occurred because the cache is not real time.

Don't use the Fix button for MRU or UserAssist type "File or directory "path" does not exist" errors (currently a user choice) -- use the Remove button for those.

jv16

This bug should already be fixed in the most recent version (1.5.2.344), could you please verify?

tullik

Facilities (backups, unencrypted UserAssist entries, et cetera) to reproduce the situation exactly are on my machines in the USA.

Adequate verification is probably possible on this machine in Norway.

I proceeded as follows:

1. Normal 1.5.2.344 Registry Cleaner scan listed 383 lines; 14 items (7 HKCU/HKUS twins) are encrypted UserAssist entries for files I created but which no longer exist in the original locations. I selected the 14 lines, selected the inverse, and selected "never show again." 369 items went into SuperRegIgnoreList.dat.

2. A second normal scan listed 188 lines; the 14 target items, 5 duplicate/triplicate HKUS target items (a new, or newly noticed, bug), and 169 additional lines (is this a bug or just a characteristic of the scanning engine?). I selected the 19 lines, selected the inverse, and selected "never show again." 169 additional items went into SuperRegIgnoreList.dat.

3. A third normal scan listed 23 lines; the 14 target items, 7 duplicate/triplicate HKUS target items (the new, or newly noticed, bug), and 2 additional lines. I selected the 21 lines, selected the inverse, and selected "never show again." 2 additional items went into SuperRegIgnoreList.dat.

4. A fourth normal scan showed only the 14 target items and the 7 duplicate/triplicate HKUS target items.

Next, I will try "Fix" for these 21 lines and report back -- if none are "fixable," I will have to fiddle with the file cache to reproduce (approximately) the original situation ...

tullik

Report back:

-- Unable to make any of the lines "fixable" -- will try again in the USA in late October with the then current version of PT 2006. Will close bug as "assumed fixed, unable to reproduce" unless/until other reports indicate otherwise.

-- There were no HKUS triplicates, just duplicates (which of course do not really exist in the registry). A different column sort showed each HKUS line was duplicated.

-- On rescans, all the duplicates do not show every time. During one rescan, none of the HKUS lines were duplicated.

-- The duplicate lines caused no noticed problems during "Remove" or "Fix" processing.

-- Based on spot checks for duplicates in the SuperRegIgnoreList.dat file, the additional lines picked up by rescans are due to ignore list misses.

-- Here are two minor bugs that should be fixed:

1. The "Quick select Normal" radio button stays selected when any of the top 14 scans are unchecked with a mouse click.

2. Unchecking the last two scans causes all other unchecked scans to be selected.