Read GPT hard disk on Windows XP

[Dave-H]

15 hours ago, mina7601 said:

Or you could just use Replacer, an alternative way of replacing system files without disabling Windows File Protection.

Thanks, that looks like an interesting utility, I will file it away for possible future use!

It looks as if the problem has resolved anyway.
I tried just saying 'No' to the pop-up, and the add driver dialogue popped up.
If I dismissed it, the drive mounted and worked anyway.
I then went into the driver update dialogue, told it to update the driver with what was already there, and it succeeded and the windows no longer pop up when I connect the disk, so it looks as if all is now OK.

Now I'm just trying to pluck up the courage to do another QuickMirror backup onto the drive, which will replace all the files I deleted!
I do hope the corruption problem doesn't immediately come back.
I'm going to do it in XP, as that's the configuration that isn't standard and needs to be tested.
Wish me luck!

[Dixel]

3 hours ago, Dave-H said:

Wish me luck!

Good luck, don't forget to place extremely important files elsewhere, to another backup!

[Dave-H]

Not out of the woods yet I'm afraid!

I did the QuickMirror backup in Windows XP.
It copied over 20000 files with apparently no error.
Ran chkdsk in the drive, no problems.
Rebooted, remounted the drive, ran chkdsk again, again no problems.
So far, so good!

Booted into Windows 10, mounted the drive, ran chkdsk.
Errors, but nowhere nearly as many as I feared.

Microsoft Windows [Version 10.0.19045.4046]
(c) Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>chkdsk /f t:
The type of the file system is NTFS.
Volume label is BACKUP.

Stage 1: Examining basic file system structure ...
  109824 file records processed.
File verification completed.
 Phase duration (File record verification): 2.20 seconds.
  4 large file records processed.
 Phase duration (Orphan file record recovery): 0.00 milliseconds.
  0 bad file records processed.
 Phase duration (Bad file record checking): 0.52 milliseconds.

Stage 2: Examining file name linkage ...
  9 reparse records processed.
Correcting error in index $I30 for file A814.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file A814.
Sorting index $I30 in file A814.
Deleting index entry backupHistoryInfo.xml in index $I30 of file F732.
Deleting index entry BACKUP~1.XML in index $I30 of file F732.
Deleting index entry CATEGORY_ICON in index $I30 of file F732.
Deleting index entry CATEGO~1 in index $I30 of file F732.
Deleting index entry SmartSwitchBackup_back.json in index $I30 of file F732.
Deleting index entry SMARTS~2.JSO in index $I30 of file F732.
Deleting index entry Video in index $I30 of file F732.
Deleting index entry DCIM in index $I30 of file F9B3.
Deleting index entry Image Files in index $I30 of file F9B4.
Deleting index entry IMAGEF~1 in index $I30 of file F9B4.
Deleting index entry Sound Files in index $I30 of file F9B4.
Deleting index entry SOUNDF~1 in index $I30 of file F9B4.
Correcting error in index $I30 for file 11EC3.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 11EC3.
Sorting index $I30 in file 11EC3.
Correcting error in index $I30 for file 11F98.
Correcting error in index $I30 for file 11F98.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 11F98.
Sorting index $I30 in file 11F98.
Correcting error in index $I30 for file 126BA.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 126BA.
Sorting index $I30 in file 126BA.
Correcting error in index $I30 for file 128F3.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 128F3.
Sorting index $I30 in file 128F3.
Correcting error in index $I30 for file 12926.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 12926.
Sorting index $I30 in file 12926.
Correcting error in index $I30 for file 1299F.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 1299F.
Sorting index $I30 in file 1299F.
Deleting index entry 2014 Pagoda Visit 03.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 04.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 17.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 18.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 19.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 20.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 21.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 22.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 23.jpg in index $I30 of file 14DEC.
Deleting index entry 2014 Pagoda Visit 24.jpg in index $I30 of file 14DEC.
Deleting index entry 2017 April from Alastair.jpg in index $I30 of file 14DEC.
Deleting index entry 2017AP~1.JPG in index $I30 of file 14DEC.
Deleting index entry 2023 July.jpg in index $I30 of file 14DEC.
Deleting index entry 2023 October with Lynda and Bob 01.jpg in index $I30 of file 14DEC.
Deleting index entry 2023 October with Lynda and Bob 02.jpg in index $I30 of file 14DEC.
Deleting index entry 2023 October with Lynda and Bob 03.jpg in index $I30 of file 14DEC.
Deleting index entry 2023JU~1.JPG in index $I30 of file 14DEC.
Deleting index entry 2023OC~1.JPG in index $I30 of file 14DEC.
Deleting index entry 2023OC~2.JPG in index $I30 of file 14DEC.
Deleting index entry 2023OC~3.JPG in index $I30 of file 14DEC.
Deleting index entry 20D7D2~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20D7D6~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20D7DE~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20E7DA~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20E7DE~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20EFCA~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20EFCE~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20F3D2~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20F3DA~1.JPG in index $I30 of file 14DEC.
Deleting index entry 20F3DE~1.JPG in index $I30 of file 14DEC.
  113184 index entries processed.
Index verification completed.
 Phase duration (Index verification): 17.72 seconds.
CHKDSK is scanning unindexed files for reconnect to their original directory.
Recovering orphaned file U14560~1.PNG (A8DF) into directory file A814.
Recovering orphaned file U14560~2.PNG (A8E0) into directory file A814.
Recovering orphaned file U14561~1.PNG (A8E1) into directory file A814.
Recovering orphaned file u14561_states.png (A8E1) into directory file A814.
Recovering orphaned file U14561~2.PNG (A8E2) into directory file A814.
Recovering orphaned file u14561_states-r.png (A8E2) into directory file A814.
Recovering orphaned file U14572~1.PNG (A8E3) into directory file A814.
Recovering orphaned file u14572_states.png (A8E3) into directory file A814.
Recovering orphaned file U14572~2.PNG (A8E4) into directory file A814.
Recovering orphaned file u14572_states-r.png (A8E4) into directory file A814.
Skipping further messages about recovering orphans.
  1289 unindexed files scanned.
  1289 unindexed files recovered to original directory.
 Phase duration (Orphan reconnection): 0.00 milliseconds.
  0 unindexed files recovered to lost and found.
 Phase duration (Orphan recovery to lost and found): 3.04 milliseconds.
  9 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 2.09 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 55.16 milliseconds.
  1680 data files processed.
 Phase duration (Data attribute verification): 0.51 milliseconds.
Correcting errors in the master file table's (MFT) BITMAP attribute.
CHKDSK discovered free space marked as allocated in the volume bitmap.

Windows has made corrections to the file system.
No further action is required.

   2861586 MB total disk space.
1593509280 KB in 83802 files.
     26924 KB in 1682 indexes.
         0 KB in bad sectors.
    264984 KB in use by the system.
     65536 KB occupied by the log file.
1336463896 KB available on disk.

      4096 bytes in each allocation unit.
 732566271 total allocation units on disk.
 334115974 allocation units available on disk.
Total duration: 28.34 seconds (28348 ms).

C:\WINDOWS\system32>

Obviously there shouldn't be any of course!

I then did another QuickMirror backup in Windows 10.
It replaced a lot of files.
I notice that the chkdsk log says "Skipping further messages about recovering orphans."
That presumably means that there could be many thousands more which aren't being recorded!

Have decided that was clean, I went back to XP.
Ran chkdsk, and there were a huge number of errors again, and chkdsk is now permanently hanging when it's recovering orphaned files, and never completing.

So, I really do not know what is happening here.

I think what I will do now is go back to my original 2TB backup drive, and try the whole operation with that.
If that shows no problems, either the 3TB drive I've got is indeed faulty, or it's because it's over 2TB.

If it shows the same problem, I can only assume that this has always been happening, and I've just never been aware of it before!

[Dave-H]

OK, another update!

@Andalu @jaclaz

I tried using other drives, but without success.

The first one I tried was the original backup drive, a 2TB Western Digital drive.
It worked very slowly with chkdsk, and I quickly discovered that this was because there were a large number of controller errors with it.
This was happening in Windows XP and Windows 10.

I couldn't resolve this, so I decided to try with another drive I had as a spare, which could be wiped if necessary.
That is a 500GB Seagate Barracuda drive, from the same series as the 3TB drive I've been trying to use.
Exactly the same result, slow intermittent operation with large numbers of controller errors being logged.

I wondered if this was because of the drives being extended partitions on MBR disks, so I reformatted the 500GB drive with a primary GPT partition.
Exactly the same, loads of controller errors, in XP and 10!

I don't know why this is. I went back to the original 3TB disk, no controller errors!
It was like the system would work with this disk, and only this disk, which doesn't make any sense to me!

Because of this problem, I haven't been able to test whether the chkdsk errors between XP and 10 happen with all disks, or just the one I'm trying to use.
Any ideas very gratefully received!
Thanks, Dave.

[Andalu]

@Dave-H

Have you always used QuickMirror in your tests? Have you tried with explorer.exe?

It seems to be also faster in copying than QuickMirror, at least that is what I detected on my Z790 system.

I had tried to copy about 1.11 TB of data with QuickMirror from one Seagate GPT disk to another Seagate GPT disk (both connected to the asmedia card):

on the first attempt, the copy suddenly stopped with the source disk blocked after almost 87GB copied (fortunately, no data loss occurred).

On the second attempt, because QuickMirror was taking too long, I decided to abort the copy by clicking the corresponding "pause" button, but it continued to proceed without interruption for over 2 minutes until I was forced to abort it via ProcessExplorer.

At the end of the copy (with almost 120GB copied) chkdsk did not detect any problems in both Win10 and XP, even after a disconnection and reconnection.

 

So far, I have never detected the controller errors you reported for any of my five GPT disks in the two systems where they were connected to the asmedia cards.

Edited February 25 by Andalu

[Andalu]

@Dave-H

you could make this attempt:

- clone the XP disk to the spare drive;
- install the asahci32 v2.0.3.2 driver for the intel sata controller (otherwise v2.0.3.1 which works for all chipsets from Ivy/Sandy bridge to Raptor Lake boards);
- connect the GPT disks to the intel sata port and copy the files with explorer.exe.

That way you will be able to understand whether the errors depend on the disks, the asmedia card or the socket it is plugged into, the riser and its power, the cables, etc.

 

[jaclaz]

These reports seem to lead to issues with some form of cache (or rather missing cache) and/or de-synchronization between device (and/or its driver) and application.

It seems like the Quickmirror is attempting to send more data than the system can bear or the system cannot tell to Quickmirror that it should slow down the sending of data.

The problem might be in any point of the chain, but it still smells of something software related more than hardware.

On the other hand the chkdsk slowness and controller errors seem a lot like "pure hardware" error (flaky SATA cable or connectors?[1]).

jaclaz

 

[1] in the (good?) ol' SCSI times there was a saying - if I remember correctly originally proposed by Jerry Pournelle - to the effect of "when you have a disk problem check everything, but the problem is always the cable", with IDE those issues were rare (with the exception of the madness that was - for a period of time - the cable select often problematic implementation) with SATA they are far less common than SCSI in my experience, still I would try different cables.

[D.Draker]

I totally agree with jaclaz, I had numerous troubles, and not only with those chinocrap cables, but also with their poorly soldered fittings. Those may be oxidized, degraded, and even faulty right from the start.

[Dave-H]

2 hours ago, jaclaz said:

These reports seem to lead to issues with some form of cache (or rather missing cache) and/or de-synchronization between device (and/or its driver) and application.

It seems like the Quickmirror is attempting to send more data than the system can bear or the system cannot tell to Quickmirror that it should slow down the sending of data.

The problem might be in any point of the chain, but it still smells of something software related more than hardware.

On the other hand the chkdsk slowness and controller errors seem a lot like "pure hardware" error (flaky SATA cable or connectors?[1]).

jaclaz

 

[1] in the (good?) ol' SCSI times there was a saying - if I remember correctly originally proposed by Jerry Pournelle - to the effect of "when you have a disk problem check everything, but the problem is always the cable", with IDE those issues were rare (with the exception of the madness that was - for a period of time - the cable select often problematic implementation) with SATA they are far less common than SCSI in my experience, still I would try different cables.

Using QuickMirror has never shown any problems like this before, and the backup disk has always been connected via an add-on card, never directly connected to the motherboard.
It could be that the Asmedia card is somehow inferior to the Silicon Image card I was using before, but surely that's not likely, as the Asmedia card is a much more recent piece of hardware.
I will now try some file copying just using Explorer, and see if it produces the same result, just to try to eliminate QuickMirror as a possible source of the issue.

2 hours ago, D.Draker said:

I totally agree with jaclaz, I had numerous troubles, and not only with those chinocrap cables, but also with their poorly soldered fittings. Those may be oxidized, degraded, and even faulty right from the start.

The first thing I checked of course was the connections, but remember that it works fine with the 3TB disk, there are no controller errors, there are with the other two disks.
All I'm doing is sliding one disk out of the enclosure, and then sliding another one in. Nothing else is being changed. I cannot explain this. 

[Dave-H]

11 hours ago, Andalu said:

@Dave-H

Have you always used QuickMirror in your tests? Have you tried with explorer.exe?

It seems to be also faster in copying than QuickMirror, at least that is what I detected on my Z790 system.

I had tried to copy about 1.11 TB of data with QuickMirror from one Seagate GPT disk to another Seagate GPT disk (both connected to the asmedia card):

on the first attempt, the copy suddenly stopped with the source disk blocked after almost 87GB copied (fortunately, no data loss occurred).

On the second attempt, because QuickMirror was taking too long, I decided to abort the copy by clicking the corresponding "pause" button, but it continued to proceed without interruption for over 2 minutes until I was forced to abort it via ProcessExplorer.

At the end of the copy (with almost 120GB copied) chkdsk did not detect any problems in both Win10 and XP, even after a disconnection and reconnection.

 

So far, I have never detected the controller errors you reported for any of my five GPT disks in the two systems where they were connected to the asmedia cards.

The controller errors are a completely unexpected mystery. Why they should happen with two disks and not with a third disk I cannot explain.
I will now do some mass file copying tests with Explorer, just to see if QuickMirror is causing the problem.

10 hours ago, Andalu said:

@Dave-H

you could make this attempt:

- clone the XP disk to the spare drive;
- install the asahci32 v2.0.3.2 driver for the intel sata controller (otherwise v2.0.3.1 which works for all chipsets from Ivy/Sandy bridge to Raptor Lake boards);
- connect the GPT disks to the intel sata port and copy the files with explorer.exe.

That way you will be able to understand whether the errors depend on the disks, the asmedia card or the socket it is plugged into, the riser and its power, the cables, etc.

 

I'm using 2.0.3.1 at the moment, with version 2.0.3.0001 of asachci32.sys and version 1.0.0.1 of ahcipp32.dll, I assume that's OK.
I'm not using a riser, if you remember there was no room to physically get it in!
The disk is connected to one of the SATA ports on the card, with a flying lead to an eSATA socket on a backplate.
The SATA sockets on the card are apparently electronically identical to the eSATA sockets on the card, there is just a passive jumper switchover system between them.

 

[D.Draker]

3 hours ago, Dave-H said:

The first thing I checked of course was the connections, but remember that it works fine with the 3TB disk, there are no controller errors, there are with the other two disks.
All I'm doing is sliding one disk out of the enclosure, and then sliding another one in. Nothing else is being changed. I cannot explain this. 

Well, I think I was the first one to point out to that questionable connections, and yes, I remember you checked them. but what puzzles me, I have the same card, I can post pictures (in case of doubts). I use it on a similar to your motherboard (Siemens with Xeon), the same year of manufacturing I guess, I have almost zero troubles with it, apart from it overloading, my PCI express when I copy the files and play a game, all at once, I wrote about it. I use it in conjunction with 6TB drivers.

No errors at all. But I'm on Vista.

 

[Dave-H]

OK, a bit of an update!

I decided to delete the backup of my mobile phone from the backup drive.
Apart from anything else, over 20000 image files are duplicated on the drive, as they are both in their original folders, and also in the phone backup, which includes the phone's SD card where copies of them are so that I can view them on my phone!
The phone backup folders seem for some reason to be generating the vast majority of the chkdsk errors, and it's confusing as I don't know, if it says that a particular image file is corrupt, whether it's the copy in the original backed up folder, or in the backed up phone backup folder!

Having done that, the number of errors has drastically reduced again.
I'm still getting clean chkdsk runs in XP which then show errors in 10 without even manually accessing the drive, and vice versa.

The errors are not severe, no cross-linked files or anything like that, for instance in XP it keeps telling me it's deleting the index for a file called 'bootTel.dat'.
If I allow it to do that, it's fine until I've been in Windows 10, and then the same error comes back in XP!
That file has never been on the backup drive as far as I know, it seems to be a file that you might find in the root of the Windows 10 system drive, caused by a recovery operation, but nowhere else. That is another mystery!

I was wondering whether to copy the phone backup back to the drive using Windows Explorer, just to see if the problems come back, which would exonerate QuickMirror as the cause of the errors. If I do that, my instinct would be to do it in XP, as that's what's really being tested.

Incidentally, do we know for sure that the Windows XP version of chkdsk will work correctly with drives over 2TB, bearing in mind that Windows XP was never designed to use drives that big?
Is it possible that the XP chkdsk is actually malfunctioning with the 3TB drive, and erroneously showing errors which aren't there, or even perhaps causing them?
I guess the chkdsk from Server 2003 isn't worth trying?


 

[Dave-H]

Another update.

I've now updated the drivers for the Asmedia card, to version 3.2.0.0 on XP, and 3.2.3.0 on Windows 10.
As you say @Andalu the drive now no longer appears in the 'safely remove hardware' applet, although the Blu-ray drive still does appear.
That's not really an issue, as I can still use 'HotSwap!' to 'eject' the drive.

I've got a card coming hopefully tomorrow to replace the Silicon Image eSATA card I was using for the backup drive before, and for the internal archive drive.
It's one of these, and it's costing me a bomb to get it shipped from the States, but I hope it will give me two internal SATA connections that I can use for the Blu-ray drive and the internal archive drive. It claims to have drivers for Windows 98, I will not be pleased it that turns out not to be the case!
The card even has an IDE connector on it, but I don't think I'll need that as my board already has one (it's being used for an ancient DVD-RAM drive!)

When the backup drive is the only thing connected to the Asmedia card, things will hopefully be simpler.

Changing the drivers doesn't seem to have made much difference, although the chkdsk readouts are pretty clean now between XP and 10.
The crunch will come when I write a lot of files to the drive again, I suspect!
I'm actually not going to put my phone backup back onto the drive again, I'm going to use another drive, very likely just a USB memory stick, to back that up.
It is after all actually a backup of a backup, just in case the phone dies, or I lose it, and the original backup drive dies!

I'm almost more puzzled now as to why the other 500GB drive is not working with the card, although this is a bit off-topic, of course.
I'm almost 100% sure that there's nothing wrong with the drive, and in fact another drive produced the same result.
Further tests seem to indicate that reading the drive is fine, blisteringly fast and no errors.
Writing is the complete opposite, very slow and masses of errors in the event log.
I was clutching at straws that updating the drivers might help this, but it hasn't.
It's the same in Windows XP and Windows 10, so it must be something quite fundamental, and yet the 3TB drive shows no controller errors at all!
I cannot explain that.

[jaclaz]

I think that that SYBA card is SATA 1 (1.5Gbs), not exactly "bleeding edge":

https://www.newegg.com/syba-sd-via-1a2s-sata-ide/p/N82E16816124009

It has a VIA VT6421(A) chip, so you should be covered:

http://toastytech.com/files/w95stuff.html

jaclaz

P.S.: I don't think it will be much different from this one:

https://www.ebay.co.uk/itm/166617600874

"Free 3 day postage

Located in: Amlwch, United Kingdom"

Edited February 27 by jaclaz

[Dave-H]

Thanks, but that card on eBay doesn't have two internal SATA ports on the card, which is what I want.
One of them is an external port.
I'm pretty sure that the Vantec ST300 Silicon Image based eSATA card that I was using before is only SATA 1 too, so I won't notice any difference!
I'll let you know how I get on when the card arrives, hopefully later today.
Cheers, Dave.