Questions about Spinrite 6.1

[JRR]

Hello, I have several questions for using spinrite 6.1:
1. If bad sectors or blocks are found, and dynastat cannot repair them, what happens with these bad sectors? Are sectors marked as bad and not used anymore or are sectors renumbered? My experience is, that after running spinrite and restarting on the same disk, the same bad sectors are found and "excercised" by dynastat again
2. When I use spinrite and want to interrupt the testing, how can I restart at the point where I left off?On the technical log screen (in green) it says "from 000% to 100%. I tired all kind if keys, but I cannot change these percentages.
3. I use an older PC to run Spinrite 6.1 With my newer one, with the bios set in CMS mode, I can boot the CD or stick, and spinrite crashes at the ram check. When I disable the ram check, it shows the present HDDs, but then spinrite crashes (no keyboard response) so no testing possible. I run the "bootcheck" and it let me generate a stick of ISO.

Any suggestions?
Thanks
JRR

 

[PHolder]

several questions

1. Just for good measure I'll point you to the FAQ but quoting from it about Level 2 (which is what I assume you're using as it's the default)

If the drive reports any trouble reading a sector, even if that sector’s data was corrected by the drive, SpinRite will pause its forward scan to rewrite that sector’s data. This will usually repair the bits that triggered the need for error correction. If several attempts to read a sector fail, SpinRite will engage its “DynaStat” (Dynamic Statistics) data recovery and begin working to obtain a fully corrected sample of the sector’s data. It will stop the instant it’s able to obtain -- or to calculate -- the data, or after five minutes of work on a single sector. If it is never able to obtain all of a sector’s data, DynaStat will recover as much of the sector’s data as possible and will rewrite the sector with the improved mostly-recovered data.

So it is SUPPOSED to rewrite sectors. However, the drive may not accept that re-write, and that may be the experience you are having.
There is a command line option that will completely disable any recovery attempts, so BE WARNED that you WILL LOSE DATA if you use it, from the command line, it's /DYNASTAT 0.

2. As you're progressing through the setup screens to start a scan, at some point you should see text that says PRESS TAB (I think it used to be SHIFT-ENTER so check for either). Doing so should give you access to those fields. You can enter either a specific LBA# or a percentage, there should be instructions on the keys to type to change the mode. You can also supply this info on the command line (see the FAQ.)

3. If your PC is crashing on the memory test, you should probably believe that your PC has bad memory. It's unfortunately all to common. There are other memory testing techniques you could use, there's one built into Windows, there's also a free tool like https://www.memtest86.com/ .

 

[JRR]

1. Just for good measure I'll point you to the FAQ but quoting from it about Level 2 (which is what I assume you're using as it's the default)

So it is SUPPOSED to rewrite sectors. However, the drive may not accept that re-write, and that may be the experience you are having.
There is a command line option that will completely disable any recovery attempts, so BE WARNED that you WILL LOSE DATA if you use it, from the command line, it's /DYNASTAT 0.

2. As you're progressing through the setup screens to start a scan, at some point you should see text that says PRESS TAB (I think it used to be SHIFT-ENTER so check for either). Doing so should give you access to those fields. You can enter either a specific LBA# or a percentage, there should be instructions on the keys to type to change the mode. You can also supply this info on the command line (see the FAQ.)

3. If your PC is crashing on the memory test, you should probably believe that your PC has bad memory. It's unfortunately all to common. There are other memory testing techniques you could use, there's one built into Windows, there's also a free tool like https://www.memtest86.com/ .

Thank you for your quick answers. I have been reading these FAQs for hours, but I must have missed the answers you gave. I am going to study now the virtualbox setup for my latest machine, which is standard using UEFI. Thanks again JRR

 

[Scott]

3. If your PC is crashing on the memory test, you should probably believe that your PC has bad memory. It's unfortunately all too common. There are other memory testing techniques you could use, there's one built into Windows, there's also a free tool like https://www.memtest86.com/ .

I'm going to disagree on this one. I have one machine that craps out during the RAM test every time, and yet I've run MemTest86 for hours and it's found no problems. Additionally, on that machine, when I run SpinRite 6.1 with the noramtest parameter, it will run for 5 to 10 minutes and then the machine craps out. I didn't report this behavior during testing because it's on my 2012 MacBook Pro, and I figured this was just weird behavior due to the Mac's quirky BIOS emulation. And nobody else reported any issues like this.

But now I'm thinking there are PCs that behave this way too. I'm sure vendors releasing new machines over the last 5 to 7 years, even with legacy / CSM modes, didn't do much testing with an x86 real mode OS like FreeDOS.

 

[callump99]

1. Just for good measure I'll point you to the FAQ but quoting from it about Level 2 (which is what I assume you're using as it's the default)

So it is SUPPOSED to rewrite sectors. However, the drive may not accept that re-write, and that may be the experience you are having.
There is a command line option that will completely disable any recovery attempts, so BE WARNED that you WILL LOSE DATA if you use it, from the command line, it's /DYNASTAT 0.

2. As you're progressing through the setup screens to start a scan, at some point you should see text that says PRESS TAB (I think it used to be SHIFT-ENTER so check for either). Doing so should give you access to those fields. You can enter either a specific LBA# or a percentage, there should be instructions on the keys to type to change the mode. You can also supply this info on the command line (see the FAQ.)

3. If your PC is crashing on the memory test, you should probably believe that your PC has bad memory. It's unfortunately all to common. There are other memory testing techniques you could use, there's one built into Windows, there's also a free tool like https://www.memtest86.com/ .

Your point 3 I'm very interested in. I've used SR6.1 on 3 PCs so far one no problems, one with one NVMe disk that can't be "seen" (mentioned in another post) and another where the memory test doesn't even really start just hangs immediately (says ": Errors" and "Total patterms tested: 0" and doesn't show any "Erroneous bits found". I have two DIMMs of 2GB each. Originally, it had both in, tried it with one DIMM in one slot and did all the permutations DIMM1 slot 1, DIMM 2 slot 1, DIMM1 slot 2, DIMM2 slot 2 all fail. It is an old PC pre UEFI so I had to get an old version of memtest86. It runs memory tests no problems against individual DIMMs and against both DIMMs together. Run SR6.1 again and it dies as before. What now?

Now running a level 2 against my disks after using "noramtest". Not sure I want to run a level 4...... or do I just ignore the SR memtest failures?

Hmmmmm.

Callum

 

[PHolder]

Well the problem with RAM testing is that there are no guarantees that a problem is found if it's not reproducible by what a test does. I had a machine with failed DDR3 that ran fine for months at a time and then randomly would crash one of the VMs running on it. I could never reproduce it when I wanted, but finally it got worse, or something, and memtest86 actually caught it. It could simply be fixed by re-seating the DIMMs but it wasn't in my particular case.

Or it could be something else completely, masquerading as RAM problems. Some sort of weird IRQ conflict or something. There are bad BIOSes that corrupt memory randomly with USB accesses above the 128GiB limit. (Steve tried to detect/block that particular problem, but it's just an example of how things are hard to pin down.)

My solution was to get a dedicated device to run SpinRite on, the ZimaBoard. That has the best hope of being a low cost device that is known to work because that is what Steve himself used for development.

I will also remind you that you could engage with GRC Support (aka Greg) via email if you think there is something funky with the RAM testing built into SpinRite... but that would be a last resort IMHO as so many people seem to not be having the issue.

 

[222computer]

I ran a 2Tb hard drive at level 3. I have about 90 sectors that spinrite says “none of its data could ever be recovered”. I have 7 sectors than 71 sectors than 7 sectors etc that can’t be recovered but the are separated by sectors that can be recovered. They’re all at 70.4483%. Should I run spinrite again to see if these sectors can be recovered (and if so at what level) or are these sectors toast?
Thanks

 

[ColbyBouma]

Should I run spinrite again to see if these sectors can be recovered (and if so at what level) or are these sectors toast?

They're toast. By default, SpinRite overwrites the sectors whether it recovered all of the data or not. To override this behavior, you have to launch SpinRite with the NoRewrite parameter.
https://gitlab.com/GRC-Community/spinrite-6.1-wiki/-/wikis/Command-Line#norewrite

 

[222computer]

They're toast. By default, SpinRite overwrites the sectors whether it recovered all of the data or not. To override this behavior, you have to launch SpinRite with the NoRewrite parameter.
https://gitlab.com/GRC-Community/spinrite-6.1-wiki/-/wikis/Command-Line#norewrite

Thanks Colby!

 

[DanR]

@222computer, As Colby noted, the data in these sectors is toast.

The "norewrite" CL switch would typically be used with the first SR scan to preserve any unrecoverable data for subsequent data recovery activity.

Since the data in those sectors is now toast, you might consider using the "dynastat 0" CL switch: spinrite dynastat 0

That will typically cause the drives firmware to (in most cases) reallocate the bad sectors. But it leaves two important questions unanswered:

What caused those sectors to fail?

Will that "cause" result in adjacent sectors failing at some point?

This drive would seem to be a good candidate for SpinRite dev testing - someday.

I would not trust it with important data however.

 

[222computer]

@222computer, As Colby noted, the data in these sectors is toast.

The "norewrite" CL switch would typically be used with the first SR scan to preserve any unrecoverable data for subsequent data recovery activity.

Since the data in those sectors is now toast, you might consider using the "dynastat 0" CL switch: spinrite dynastat 0

That will typically cause the drives firmware to (in most cases) reallocate the bad sectors. But it leaves two important questions unanswered:

What caused those sectors to fail?

Will that "cause" result in adjacent sectors failing at some point?

This drive would seem to be a good candidate for SpinRite dev testing - someday.

I would not trust it with important data however.

Thanks Dan. I’ll give that a try.