Announcement

Collapse
No announcement yet.

Corruption Still occurring in latest build v11.2.2704700334

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Corruption Still occurring in latest build v11.2.2704700334

    Sadly, chkdsk reported 2 corrupted entries a couple of days ago. I have been obsessively running chkdsk on each and every occassion that i roll back, take a snapshot, defrag, boot up etc, etc.
    in an effort to try to catch the corruption exactly at time of occurrence but this takes a toll and i confess that as time goes on i get complacent. Well in this instance i didnt do a chkdsk after boot up and it was at least half hour before i clicked on Excel and it flashed up an exception error (or something...any error messages like that tell me that RB has corrupted something). I then immediately looked at my Avast icon in the system tray and noticed an X in it. Yep something was amiss. Ran chkdsk and corruption reared its ugly head. I dont know if the corruption occurred at boot time or worse on the fly.

    I didnt keep any data files as HDS seem uninterested when i've offered them in the past. The thing is that i really dont use my PC that often (personal use). However i do do alot of restarts, installs, rollback and so on. I think that in an environment where RB is left running all day (even 24 hours a day) then it runs reliably (until it doesnt). But in situations like mine its really tested and the ticking time bomb is revealed.

    As has already been advised many times, make sure your backups are always up to date because even though i still think RB is great (when it works) it just isn't dependable and i think i never will be...

  • #2
    Originally posted by carfal View Post
    As has already been advised many times, make sure your backups are always up to date because even though i still think RB is great (when it works) it just isn't dependable and i think i never will be...
    Now that is a very weird statement How can you think "RB is great (when it works)" when it "just isn't dependable" and you think "it never will be"? That's crazy! Who would purchase a software product that had that kind of user review or reference? Do people buy software that works only some of the time (at $69 a pop... or any price for that matter)? I think not, my friend. What you're describing above is what made me walk away from the RBrx universe a while back for a more reliable solution. HDS seems to have lost control over the development of this product and as a result, it's gotten even flakier over the years... a sorry state for me as I was always a lover of snapshot capability but never at the expense of System reliability. That just doesn't make any sense.

    I do hope they're able to help you with this issue and, at some time in the future, turn this product around into a more robust & reliable solution. There's definitely a need for the snapshot niche.
    Last edited by Froggie; 07-09-2019, 05:51 AM.

    Comment


    • #3
      Hi Froggie. I guess when i read it your right. It seems like I'm contradicting myself but the fact of the matter is that i really do think RB is "Great". So much so that i just cant let go of it. The "Great" downside also is that it cant be dependent on. It pains me to admit it. Like I've stated i use my PC for personal use and as you know I've been using RB for many...many years so I've setup a bullet proof recovery system. It's sad that i have to do this (or maybe prudent in any circumstance) but it doesnt bother me to take such precautions any longer.

      People will probably say I'm crazy and should just use MR as a snapshot program and let RB go but the truth is that nothing comes close to RB speed and for my personal use, it's easy for me to capture the corruption at it's earliest point and then use MR to recover if RB is completely trashed (which for a few versions now seems to only affect a few snapshots so MR is not required).

      I also agree that i cant recommend RB to anyone to buy. All i can do is tell people of my experience with it and how i deal with the issues. That way should someone want to play with the devil, they go in informed...

      EDIT: Im long past actively helping HDS solve their corruption issues. This has been an intermittent problem throughout ALL of their versions.

      Comment


      • #4
        Originally posted by carfal View Post
        I also agree that i cant recommend RB to anyone to buy. All i can do is tell people of my experience with it and how i deal with the issues. That way should someone want to play with the devil, they go in informed...
        I LUV that QUOTE

        I'm sure all of us thank you very much for your hard learned experience in this area... it can be painful but at least you offer some real guidance to dealing with that pain. Good luck and stay vigilant!

        Comment


        • #5
          Thank you, Carfal and Froggie, for the continued warnings. I'm grateful for them, and thanks to the two of you, I now do scheduled daily backups with Macrium Reflect. But in my experience, Rollback Rx version 11.0, build 2703845388, doesn't have any corruption problems. At least I haven't seen any over quite a few months, with a rollback every couple of weeks or so.

          Comment


          • #6
            Hi dbolotin. I'm glad that we are able to warn and/or help people decide if they should try this program. I do recall that build 388 was stable on my machine as well. However I'm happy to keep installing the latest build and report back my experiences. For me, there's no fun in playing it safe

            Comment


            • #7
              Well, just had a major meltdown. Tried to roll back about 6 snapshots deep and none of them would load upon reboot. Tried about 4 snapshots. Black screen and something about "Loadufiimage ....error 0x0E" or something to that effect. I didnt have any hope of recovery from this and was about to get my trusty MR, thought lets try the last snapshot for fun and blow me down it loaded. Ran chkdsk and chiver me timbers () no errors????

              OK, Im done testing their "Space saving mode (SSM)". I never played with the baseline deletion because the one time i did it tripled the next snapshot in size ( if original baseline was 60GB, the new resulting baseline would increase to over 180GB). I just left it at default. Took my snapshots, deleted, rolled back and so on. As per default settings, RB would switch to "Fast Restore Mode (FRM)" everytime you roll back and switch back to SSM at next snapshot taken ( or after 7hrs use).

              So I've uninstalled, changed "hybrid=1" to "hybrid=0" in the "setup.ini" file and have reinstalled in the standard FRM.

              ‚ÄčLets see what happens now.....

              Comment


              • #8
                Well that was a short experiment. Corruption again!

                Only had 2 snapshots plus baseline.

                All i did was install with Hybrid=0 option. Took first snapshot and locked it. Manual Defrag. Did some forum surfing, etc. Took another snapshot. Deleted previous Snapshot. Manual defrag. Shutdown computer. A few hours later booted up again. Checked emails,etc etc. Took another snapshot. Deleted previous. Manual defrag. Updated Teamviewer. Took another snapshot. Deleted previous. Manual defrag. Now at this stage still only have 3 snapshots showing. For a test i decided to rollback to the last snapshot (the one i just took).

                PC rebooted, Loading Snapshot bar progressed and i think i saw the rollback defrag bar briefly flash up as well when the Win 10 Blue automatic repair window shows up...#^$%$%$* off! Tried rolling back to second snapshot and low and behold it booted up normally. Chkdsk reported no issues.

                This is too much even for me. The versions since Space saving mode was introduced (v11.1 onwards) are out right dangerous to use for the average user. I cant believe that they aren't inundated with tech calls.

                Im following mrdutchies model and going back to version 388 till HDS get their act together.

                Comment


                • #9
                  But now I'm not sure that even version 388 is safe. At all events, it turns out that I had corrupted system files (which made it impossible to install Windows updates). I think I was able to repair my system. But if RollbackRx is the culprit, it doesn't help to supplement its snapshots with scheduled backups with Macrium Reflect, since Macrium will merely back up the corrupted files. Now I'm considering, at any rate, the unpleasant alternative of abandoning RollbackRx altogether.

                  Comment


                  • #10
                    Are you saying that v11.0.2703845388 has corrupted your system as well?

                    It's true that you need to make sure you have a consistent file system before making an MR backup. However it's my experience that MR detects if the file system in not consistent before it takes its image. As a rule i always run chkdsk to confirm my file sytem is consistent before i do a MR backup.
                    Last edited by carfal; 07-11-2019, 07:55 PM.

                    Comment


                    • #11
                      Carfal, All I know is that something corrupted my system files, and that v11.0.2703845388 is the version of RollbackRx that I have been using. I don't know whether RollbackRx was the culprit or not. Also, MR didn't warn me about this corruption. (Since I schedule daily backups with MR, I wouldn't want to take the trouble to run chkdsk before each one.) The only way I found out about the corruption is that the Windows 10 July updates wouldn't install. Then I ran sfc /scannow, which told me about the corruption but said it couldn't repair all the files. Then I ran a DISM /Online /Cleanup-Image /CheckHealth, and that seems to have succeeded in fixing things.

                      Comment


                      • #12
                        Be aware that the MR FileSystem Check is not as robust as a chkdsk /f but is adequate in most cases.

                        Comment


                        • #13
                          That's good to know, Froggie. But the MR FileSystem Check didn't flag the system file corruption that was preventing my Windows 10 updates from installing. I don't know whether chkdsk would have found it or not. I discovered it by running sfc /scannow.

                          Comment


                          • #14
                            Dont know whats going on here, but HDS have released another version of RB with the same build number. It was released on July 11.

                            Below is a comparison of the file differences in the Zip file. The red files on the left are the newer, updated files.

                            BC 2019-07-13_13-56-33.jpg

                            Looks like major code changes but no word why??

                            Going to install and test to see if corruption has been improved....

                            Comment


                            • #15
                              C:\WINDOWS\system32>chkdsk c:
                              The type of the file system is NTFS.

                              WARNING! /F parameter not specified.
                              Running CHKDSK in read-only mode.

                              Stage 1: Examining basic file system structure ...
                              598016 file records processed.
                              File verification completed.
                              6824 large file records processed.
                              0 bad file records processed.

                              Stage 2: Examining file name linkage ...
                              2357 reparse records processed.
                              722324 index entries processed.
                              Index verification completed.
                              CHKDSK is scanning unindexed files for reconnect to their original directory.
                              1 unindexed files scanned.
                              Detected orphaned file pkg190713000000003d.bin (54ED), should be recovered into directory file 2EDFC.
                              1 unindexed files recovered to original directory.
                              0 unindexed files recovered to lost and found.
                              2357 reparse records processed.

                              Stage 3: Examining security descriptors ...
                              Security descriptor verification completed.
                              62155 data files processed.
                              CHKDSK is verifying Usn Journal...
                              Usn Journal verification completed.
                              The Volume Bitmap is incorrect.
                              Windows has checked the file system and found problems.
                              Please run chkdsk /scan to find the problems and queue them for repair.

                              243129343 KB total disk space.
                              88301296 KB in 236842 files.
                              166744 KB in 62156 indexes.
                              0 KB in bad sectors.
                              744387 KB in use by the system.
                              65536 KB occupied by the log file.
                              153916916 KB available on disk.

                              4096 bytes in each allocation unit.
                              60782335 total allocation units on disk.
                              38479229 allocation units available on disk.
                              Press any key to continue . . .
                              C:\WINDOWS\system32>chkdsk c:
                              The type of the file system is NTFS.

                              WARNING! /F parameter not specified.
                              Running CHKDSK in read-only mode.

                              Stage 1: Examining basic file system structure ...
                              598016 file records processed.
                              File verification completed.
                              6822 large file records processed.
                              0 bad file records processed.

                              Stage 2: Examining file name linkage ...
                              2357 reparse records processed.
                              722318 index entries processed.
                              Index verification completed.
                              0 unindexed files scanned.
                              0 unindexed files recovered to lost and found.
                              2357 reparse records processed.

                              Stage 3: Examining security descriptors ...
                              Security descriptor verification completed.
                              62152 data files processed.
                              CHKDSK is verifying Usn Journal...
                              37369840 USN bytes processed.
                              Usn Journal verification completed.
                              The Volume Bitmap is incorrect.
                              Windows has checked the file system and found problems.
                              Please run chkdsk /scan to find the problems and queue them for repair.

                              243129343 KB total disk space.
                              95264004 KB in 235560 files.
                              164548 KB in 62153 indexes.
                              0 KB in bad sectors.
                              746439 KB in use by the system.
                              65536 KB occupied by the log file.
                              146954352 KB available on disk.

                              4096 bytes in each allocation unit.
                              60782335 total allocation units on disk.
                              36738588 allocation units available on disk.
                              Press any key to continue . . .




                              The results speak for themselves. It makes me wonder how i can discover corruption in 10min of testing and the HDS QA (if it exists) says "All good here fellas. Release to the guinea pigs).

                              Looking at my history window above, this is what i did

                              This first test i protected only C and all hidden partitions except the Windows reserve space drive

                              Took first snapshot (SS) and locked it
                              Took a SS
                              Took a SS
                              Deleted previous
                              Took a SS

                              Deleted previous
                              Took a SS
                              Deleted previous
                              Took a SS
                              Deleted previous
                              Took SS "Win:RP1"
                              Took SS
                              Took SS "Win:RP2"
                              Deleted previous
                              Right clicked SS "Win:RP1" and clicked "explorer". SS mounted
                              Opened explorer and clicked some small log files
                              Closed mounted SS
                              Did the same with SS "First Snapshot"
                              Ran a manual defrag
                              Rolled back to SS "Win:RP1"
                              Upon reboot SS loaded and an auto defrag occurred then SS continued to load
                              Ran chkdsk....no errors..Looking promising
                              Rolled back to SS "First Snapshot".......loaded without incident but the first chksdk report above is the result. All hidden partitions were error free
                              Rolled back to SS"Win:RP2" ....same error
                              Tried rolling back to SS "Win:RP1" now it also has the same error whereas the first time all good?? Not very promising at all
                              At this stage rolled back to installation SS and luckily no errors. So I deleted all SS except the installation and tried the test all over again.
                              This time all snapshots were error free???? I dont know what to make of it.

                              2nd install of RB i only protected Drive C. Left hidden partitions alone.

                              Ran the same tests above except the corruption shown in the second chkdsk report above were only existent in the last 2 snapshots and it was different corruption.

                              Good news is that my system remained stable throughout all of this hence was able to gracefully recover each time. It's important to note that i learned many years ago NEVER to let chkdsk run...recipe for disaster.

                              In summary...nothings changed except the type of errors and back i go to build 388. (admittedly, i havent run this test on build 388 but i know from previous experience that it is far more stable than its later iterations)




                              Comment

                              Working...
                              X