Critical error, division overflow, at B04E in Spinrite 6.0, level 4 scan

[Mouse]

I had a critical error at B04E in a Spinrite 6.0, level 4 scan. Description was"Division Overflow error". Details below.

I would like if possible, get some advice on how to proceed. (I have submitted a report to support@grc.com)

For example, I would be grateful to know if I should:

1. Immediately restart the scan at the last location, as I understand in the case of power failure, you should do this immediately to allow Spinrite to repair drive damage which may be caused by interruption
2. Try a level 2 scan
3. Try a different boot disk
4. Try again with Spinrite after using Chckdsk /f
5. Try a Beta Spinrite 6.1 version
6. Use chckdsk /r or some other software (eg Victoria) instead of Spinrite to force my bad sectors to be marked as such, if the bug/limitation means Spinrite will not function on my computer
7. ?Anything else I could try?

(I don’t have easy access to another reliable computer that could hold the disk as my old computers are mainly failing – so this would be a last resort)

The problem I was trying to solve with Spinrite was that my computer will boot in Msconfig limited boot mode (MS software only loading) but not in normal boot mode. In normal boot mode computer crashes seemingly randomly during boot or after and, where generated, dump files give hugely variable Windebug diagnoses. Victoria hard disk analysis software reliably finds two unmarked bad sectors.

I have a pretty comprehensive backup, happily, but you never know if you have missed something critical, so I would like to repair the disk if possible.

Many thanks in anticipation if you can help.

Kind regards

Mouse



***DETAILS***

*System and drive details*

Drive being scanned was Western Digital 1 TB drive. WD10EALX - 759BA1. Drive is on SATA 0 and is Win 7 ultimate (last service pack) boot drive. SATA version is 3. Drive firmware is version 19.01H19.

Machine is Dell XPS 8300 with A06 (latest OEM version) American Megatrends 17/10/2011 Bios with Aptio setup utility. Chipset is Intel H67 (Cougar Pt) [B3]. Motherboard is Dell 0Y2MRG.


*What I did and what happened*

1. I booted from boot USB created using HP Win 98 boot disk creator recommended in the Spinrite FAQ. (Computer would not boot FreeDOS). I initiated a level 4 Spinrite scan of the Western Digital boot disk (all partitions).
2. I noted Spinrite could not access SMART info on disk. (There is no apparent setting in the Bios to allow Legacy/IDE access).
3. Spinrite proceeded to process the first 3 partitions OK - no disk defects found. On last and largest (c1TB) partition, probably the one with the drive defects, Spinrite critically errored - error location and Spinrite log info below.

*Critical Error Location info*

A critical error has occurred at B04E from which Spinrite cannot recover.....

eax: 02168A21 esi: all zeros

ebx: 00000029 edi: 0000003F

ecx: all zeros edp: 00000400

edx: 0000015A esp: 00003FEE

ds: 15EF es:15EF fs:7522

gs:0040 ss:3980 fl:0246


Last partition and performance log info

ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸

³ SpinRite 6.0, beginning level 4 operation at 7:30 pm on Jan 11th, 2023. ³

³ Licensed User: xxxxxxx Serial No: xxxxxxx³

³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ

³ Drive 1 Add-On Controller ³

³ Item 4 NTFS or OS/2 HPFS Physical Drive Details ³

³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij

³ bios support: extended "int13" hardware irq: unknown ³

³ bios drive num: 81h address style: unknown ³

³ cyls/hds/sects: 1,023 / 255 / 63 drive sectors: unknown ³

³ sector count: 1,953,525,168 determined by: unknown ³

³ total bytes: 1,000,204,886,016 ³

³ 32-bit xfers: unknown ³

³ hardware addrs: unknown dma channel: unknown ³

³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ

³ Performance Benchmarks ³

³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij

³ smart polling speed : no smart seconds ³

³ random sector access : 14.340 milliseconds ³

³ sector access velocity : 22,477,155 megabytes per second ³

³ burst transfer rate : 67,980,166 bytes per second ³

³ sustained transfer rate : 168,103,735 bytes per second ³

³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ

 

[AlanD]

Greg at support may be able to help, but this is a known problem with v6.0. Sometimes trying a different version of DOS gets round it.

Otherwise, it you have access to 6.1 and AT YOUR OWN RISK, you could try that. Remember 6.1 is still alpha software, and whilst there are no reported cases of data damage, it could happen. It depends how important the data is to you.

 

[Mouse]

OK, thanks very much Alan for your response. I have a Dell DOS USB which would be worth trying. I will also think about the alpha.

Befire I do that, should I immediately restart the scan using the same media (?possibly at the last location?), and let it complete, if it will? (I understand from the website main FAQ that in the case of power failure, you should run Spinrite whenthe power is restored to allow Spinrite to repair drive damage which may be caused by interruption?).

Or is this guidance not relevant in this case.

Kind regards

Mike

 

[AlanD]

You could try restarting from just beyond the point of failure, it may work. I don't think Steve ever got to the bottom of what causes the underlying problem. It is not in his code, but something in DOS/BIOS.

 

[Mouse]

Ok I will give it a go. Thanks very much, Alan

Mike

 

[PHolder]

but something in DOS/BIOS

There is always a risk of doing such a thing, but it may be worth checking if your machine has any BIOS updates. Perhaps whatever causes the bug that crashes SpinRite 6.0 was eventually fixed but the BIOS update was not "pushed" out, but just made available.

 

[cbrillow]

As others have mentioned, this was a long-standing issue with 6.0, particularly on larger modern hard drives. Very frustrating, as there are several reported attempts to get around it, with occasional success being reported for some of those different methods.

Some point to BIOS issues in given motherboards. If you have access to any other computers like some of us do, you might try slipping the drive into a different machine and see if it will scan in that one.

One of the things I tried when I ran into this issue several years ago was to run Spinrite from a USB stick that uses MS-DOS 6 for a host rather than FreeDOS. At one time, someone postulated that FreeDOS may have been a factor in the failure mode. I'm tempted to say that I had a positive result with this experiment, but can DEFINITELY state that it it was not a conclusive fix for every drive I tried it on. It could have also been that simply moving the drive to a different host computer may have resulted in it completing the test on another attempt.

Also, as others have mentioned, Spinrite 6.1 is very close to beta. Although the alpha versions are even riskier than betas, and you'll get warnings aplenty about not using it on important data, I've not seen any reports of a 6.1 alpha screwing anything up. If you're running this primarily to refresh the data, maybe waiting just a while longer would be a decent idea, as 6.1 is moving along very quickly. Steve seems very confident with its operation at the moment, but he would still caution you to be careful, just in case...

 

[Mouse]

Thank you all very much for your helpful suggestions which I will now try out.

I thought I'd better first get an idea of the current status of the drive so I ran a level 1 scan on the erroring item (partition) 4. This found:

• Scan ran OK without a crash
• 4 sectors with read errors - 2 more than Victoria found. presumably due to a deeer level of analysis
• these 4 sectors it marked on its status display as 'R' for 'recovered', but I think it must mean 'recoverable', since the detailed technical log said they needed to be recovered by a deeper test.
• I noted that for the first sector was initially marked as correctable by ECC, though when other secotors were added to the detailed technical log this note vanished

Could anyone guide me on how to calculate the restart % if I wish to set Spinright to restart the level 4 scan after the first erroring sector?

For example, using the data for Item 4 below is it (35,015,603+1)/1,953,525,168 = 0.0179 = 1.79% ? Or can I set it to restart on an exact sector - which would be more accurate?

Kind regards

Mike

****Detailed Techical Log extract:*****

³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ Drive 1 Add-On Controller ³
³ Item 4 NTFS or OS/2 HPFS Physical Drive Details ³
³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ bios support: extended "int13" hardware irq: unknown ³
³ bios drive num: 81h address style: unknown ³
³ cyls/hds/sects: 1,023 / 255 / 63 drive sectors: unknown ³
³ sector count: 1,953,525,168 determined by: unknown ³
³ total bytes: 1,000,204,886,016 ³
³ 32-bit xfers: unknown ³
³ hardware addrs: unknown dma channel: unknown ³
³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ Performance Benchmarks ³
³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ smart polling speed : no smart seconds ³
³ random sector access : 14.344 milliseconds ³
³ sector access velocity : 22,471,245 megabytes per second ³
³ burst transfer rate : 68,003,344 bytes per second ³
³ sustained transfer rate : 168,252,836 bytes per second ³
³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ Event ³ Drive Sector ³ Partit Sectr ³
³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ This sector contains data requiring ³ 35,015,603 ³ 6,298,547 ³
³ recovery using a deeper testing level. ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ This sector contains data requiring ³ 470,270,648 ³ 441,553,592 ³
³ recovery using a deeper testing level. ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ This sector contains data requiring ³1,087,851,443 ³1,059,134,387 ³
³ recovery using a deeper testing level. ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ This sector contains data requiring ³1,523,106,488 ³1,494,389,432 ³
³ recovery using a deeper testing level. ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄij
³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ Drive: 1, Item: 4 Graphic Status Display ³
³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ þþþRþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþRþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþRþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþRþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ þþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþþ ³
³ÍÍÍ work ÍÍÍÍ remaining ÍÍÍ completed ÍÍÍÍÍÍÍÍ sector status key ÍÍÍÍÍÍÍÍͳ
³ megabytes: 0 985,499 ³ .oO analyzing ³ R recovered ³
³ %: 0.00% 100.00%³ ú unprocessed ³ B defective ³
³ time: --:--:-- 2:13:13 ³ þ processed ³ U unrecovered ³
³ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͳ
³ SpinRite 6.0, level 1 operation completed at 6:13 pm on Jan 12th, 2023. ³
ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;

 

[Mouse]

Using a different DOS unfortunately did not work. But thanks very much for the suggestion.

DoS used was Dell DRMK Version 8.0023.11 (Build 09). They give kernel and command.com build dates so I think it is their own? I ran the scan on just Item 4 on the disk, to save time.

Results

1. Spinrite ran OK but gave exactly the same divide by zero error at B04E. All location information was the same as in the first post in the topic aprt from ds=0EEB, es=0EEB, fs=6E48, ss=327C
2. I noted that it crashed at the first defect in item 4, just after Dynstat had kicked in

I will maybe have a look to see if DR DOS still exists, as from memory that was separately coded by Digital Research.

Kind regards

Mike

 

[Mouse]

Other suggestions from your posts above. (For which thanks very much indeed.)

1. Update Bios to latest version. I have done so, but unfortunately that didn't help.
2. Mounting the drive in another computer would not be easy as I am not skilled with hardware, but I might mange it! The only suitable one I have is about 10 years older again (c2000) and will not itself boot at the moment - though possibly it would from a boot disk. Not sure it had a SATA interface - maybe. The disk with the errors is described as a SATA disk - not sure if such disks are usable with different interfaces if the computer does not have a SATA one? Does the SATA version matter? The old computer's disks were configured as RAID, I think using a separate controller card - would this complicate things? Maybe I should keep this as a possible reserve option if all else fails.
3. Using a version 6.1 alpha/beta. I have a reasonable back up so could maybe take the risk. Are the executables here: https://www.grc.com/dev/SpinRite/? Could anyone suggest a version to use as I am not familiar wth the way the versions are named? Would SR-R14.EXE be the best one? Is beta coming in days or weeks? If days I will probably wait.

Greg (thanks Greg!) has also in addition suggested by email:

1. Reducing hard disk speed in Bios. Unfortunately my Bios does not allow this.
2. Checking to see if a Western Digital test utility might be able to force the drive to repair itself. I will check this now.

Many thanks again to one and all!

Kind regards

Mike

 

[Mouse]

Updated first post in topic with additional information on bios, chipset and motherboard. Corrected Bios date.

 

[Mouse]

Just in case it is relevant I note that other reports seems to involve:

1. Large Western Digital disks
2. Disks with multiple partitions
3. Large partitions on those disks

Other reports (will add more if I find them):
https://codeverge.com/grc.spinrite.dev/error-b04e-on-a-sick-drive/1647060
https://forums.grc.com/threads/odd-spinrite-error.1032/

I would add that on my disk, SMART has identified 2 defective sectors as faulty, but has not marked them as bad and so to be ignored by the OS over an extended period. Note sure why not.

Kind regards

MIke

 

[Mouse]

I found 2 Western Digital disk test/repair tools. Thanks very much for the suggestion Greg.

1. WD Dashboard (Current). This would not run the SMART extended test on either Drive, so could not offer repair options. On one Western Digital drive the test failed with Error 7 and it hung on the other (which has no problems as far as I am aware). It could access the drives' Smart data, but that data said that there were no remapped sectors. Victoria Smart data listing says there are 2.
2. WS Data lifeguard (Older). This would run extended diagnostics but says that any repair options are destructive. (It writes zeros across the affected sectors). It could not access the SATA data from either disk for some reason.

So The WD tools I can find are altogether not awfully helpful and perhaps a bit flaky - though I guess I could risk a remap using Lifeguard if all else fails. I think I would prefer to trust a Spinrite beta though!

Probably other manufacturers have better tools…… Or maybe I have missed some WD ones…….

Kind regards

Mike