Read GPT hard disk on Windows XP

[Andalu]

Thanks @Dave-H for the clarification.

The v2.0.3.1 is not wrong but it is the only working version for all intel sata controllers. For asmedia ones you can install the most updated versions.

The latest working version for the ASM1061 chipset is the asahci32.sys v3.2.0.

Regarding bootable drives, I think there is no one-size-fits-all behavior: it can be affected by several variables such as bios and firmware.

[jaclaz]

Happy to know that it (overall) works.

I don't think that it may make a difference , but have you tried connecting the device(s) temporarily to the actual esata ports on the card?

It is possible that that checkbox only affects the esata ports but I doubt it .

Adapters from esata to sata actually exist, though they cost an awful lot of money (compared to the riser):

https://www.testsieger.de/sata-kabel/2CAZ10CRHK9T4-inline-27502-esata-stecker-an-sata-buchse-adapter.html

If you are into testing and wiling to do crazy experiments, you could try one of the "removable to fixed disk" filter drivers (cfadisk.sys, dummydisk.sys or diskmod.sys, this latter is the most recent and more featured one).

 

Edit:

Also, maybe:

https://fightingforalostcause.net/1044

(if you want to only remove the DVD/Blue-Ray), you can also remove the whole stuff (since you are running Hot-Swap):

https://msfn.org/board/topic/34987-safely-remove-hardware-iconthat-everyone-hate/

https://msfn.org/board/topic/176084-trouble-with-stobjectdll-maybe-newdevdll/

jaclaz

 

 

Edited February 18 by jaclaz

[Dave-H]

Thanks @Andaluand @jaclaz.

One way around this would be for me to connect the Blu-ray drive directly to the motherboard, and instead connect another of my drives to the card, which is in an internal swappable caddy. I have two other drives in caddies which sometimes go in there. As that is a physically removable drive, that would work around the problem, and give me the advantage that I could swap the drive in the caddy for another one without rebooting as I have to do now.

The disadvantage of that configuration would be that I would lose access to the internal caddy drive in Windows 98, unless you can tell me that there's a Windows 98 compatible driver for the Asmedia card, which I very much doubt!

I guess compromises are always inevitable with a complex multi-boot system!

I'm obviously very glad that I can now access in Windows XP the 3TB disk in the external enclosure.

@jaclaz is that eSATA to SATA adapter you linked to active or passive? I looks like it's probably passive to me.
I may be wrong, but I've always assumed that apart from the physical connector being different, eSATA and SATA are the same thing, the only difference being that eSATA connections go through different electronics to allow hot-swapping, which can't be done with standard SATA connections.

As I said earlier, I think the SATA ports on the Asmedia card are actually eSATA connections, with a passive jumper switchover between the two socket types, and my experience now would seem to bear that out. After all there's no reason why a SATA connection should not use eSATA hot-swap capable electronics, even if it's permanently connected. Obviously that doesn't apply the other way around!

If it's always treating all connected devices as removable devices, that also seems to bear out to me that the supposed SATA ports on the card are actually not that at all, they are eSATA ports pretending to be SATA ports!

The fact is that I don't want the system to treat my Blu-ray drive as a removable and non-bootable device.
If I have a problem and need to boot into a recovery environment with a boot DVD, I'm going to be in trouble with that configuration unless I physically reconnect the drive directly to the motherboard, which I can do of course, but it's a bit of a faff!

 

[jaclaz]

That adapter is entirely passive, there is no difference between sata and esata, only the shape of the connector.

No idea how that card (and its driver)  works, but at least in theory it is perfectly possible that it can distinguish between the sata and esata ports, if they are all treated the same, then of course there is no reason to prefer the esata to the sata ports.

About the Blu-Ray, and the hard drive caddy, it seems to me that your plan to swap the connections is fine.

jaclaz

[Dave-H]

@Andalu @jaclaz

What I'm thinking of doing now is to buy another Silicon Image or similar PCI card, without an eSATA connection, but with two internal SATA connections on the card.
I can then connect the Blu-ray drive to the extra connection on that card (my archive disk is already connected to the single internal connection on the card I'm already using).
Then only the 3TB drive would be connected to the Asmedia card, which should be fine.
If the new card treats the Blu-ray drive as the other PCI-E SI card did, that is to say not as a removable drive, all should be fine.

HOWEVER
I've now come up against a much bigger problem!

If I use the 3TB in Windows 10 and then go to use it in Windows XP, or vice versa, there are a huge number of file system errors on it!
I'm having to repeatedly run chkdsk to clean it up before I can use it.
There are a truly massive number of errors found every time, which seem to be all fixable, but is obviously hardly ideal!

This is after doing a backup to the drive in Windows 10 (where it showed clean) to then trying to use it in XP.

Checking file system on T:
The type of the file system is NTFS.

Chkdsk cannot run because the volume is in use by another
process.  Chkdsk may run if this volume is dismounted first.
ALL OPENED HANDLES TO THIS VOLUME WOULD THEN BE INVALID.
Would you like to force a dismount on this volume? (Y/N) Volume dismounted.  All opened handles to this volume are now invalid.
Volume label is BACKUP.
Attribute record of type 0x80 and instance tag 0x7 is cross linked
starting at 0xc68a9c6 for possibly 0xd clusters.
Attribute record of type 0x80 and instance tag 0x7 is cross linked
starting at 0xc68a9c6 for possibly 0xd clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x7
in file 0x14e00 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85504.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9eb7ec for possibly 0x135 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9eb7ec for possibly 0x135 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e1a is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85530.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ebc13 for possibly 0x2ba clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ebc13 for possibly 0x2ba clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e20 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85536.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ec358 for possibly 0x1ec clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ec358 for possibly 0x1ec clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e23 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85539.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ec83b for possibly 0x241 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ec83b for possibly 0x241 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e26 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85542.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9eca7c for possibly 0x23 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9eca7c for possibly 0x23 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e27 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85543.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ecaa0 for possibly 0x21a clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ecaa0 for possibly 0x21a clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e28 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85544.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ecece for possibly 0x1bf clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ecece for possibly 0x1bf clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e2c is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85548.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed08d for possibly 0x79 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed08d for possibly 0x79 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e2d is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85549.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed107 for possibly 0x63 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed107 for possibly 0x63 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e2e is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85550.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed2ee for possibly 0x1a clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed2ee for possibly 0x1a clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e39 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85561.
Attribute record of type 0x80 and instance tag 0x7 is cross linked
starting at 0xc950dde for possibly 0x19 clusters.
Attribute record of type 0x80 and instance tag 0x7 is cross linked
starting at 0xc950dde for possibly 0x19 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x7
in file 0x14e3f is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85567.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed372 for possibly 0xa clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed372 for possibly 0xa clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e40 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85568.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed37c for possibly 0x7 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed37c for possibly 0x7 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e41 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85569.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed383 for possibly 0x15 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed383 for possibly 0x15 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e42 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85570.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed398 for possibly 0x1f clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed398 for possibly 0x1f clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e43 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85571.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed3b7 for possibly 0x1f clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed3b7 for possibly 0x1f clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e44 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85572.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed3d6 for possibly 0x19 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed3d6 for possibly 0x19 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e45 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85573.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed3ef for possibly 0x14 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed3ef for possibly 0x14 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e46 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85574.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed403 for possibly 0x22 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed403 for possibly 0x22 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e47 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85575.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed425 for possibly 0x17 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed425 for possibly 0x17 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e48 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85576.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed43c for possibly 0x26 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed43c for possibly 0x26 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e49 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85577.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed463 for possibly 0xb clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed463 for possibly 0xb clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e4a is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85578.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed46e for possibly 0x23 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed46e for possibly 0x23 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e4b is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85579.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed491 for possibly 0xd clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed491 for possibly 0xd clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e4c is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85580.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed49e for possibly 0x27 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed49e for possibly 0x27 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e4d is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85581.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed937 for possibly 0xa1 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ed937 for possibly 0xa1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e60 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85600.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ede8f for possibly 0x34 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ede8f for possibly 0x34 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e72 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85618.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9edec3 for possibly 0x9b clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9edec3 for possibly 0x9b clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e73 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85619.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9edf5e for possibly 0x82 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9edf5e for possibly 0x82 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e74 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85620.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee183 for possibly 0x36 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee183 for possibly 0x36 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e7b is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85627.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee1b9 for possibly 0x11 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee1b9 for possibly 0x11 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e7c is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85628.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee1ca for possibly 0xe clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee1ca for possibly 0xe clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e7d is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85629.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee1d8 for possibly 0x2c clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee1d8 for possibly 0x2c clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e7e is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85630.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee205 for possibly 0x4c clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee205 for possibly 0x4c clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e7f is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85631.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee251 for possibly 0x5a clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee251 for possibly 0x5a clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e80 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85632.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee2ab for possibly 0x3 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee2ab for possibly 0x3 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e81 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 85633.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee2af for possibly 0x61 clusters.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0xc9ee2af for possibly 0x61 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x14e82 is alread

For more information, see Help and Support Center at http://localhost:90/redirect.php.

And that's just the errors which were recorded in the Windows log, I'm sure there were many many more!
I really don't know what to do about this.

[Andalu]

@Dave-H

were the errors detected by chkdsk in XP or in Win10?

 

Your idea of getting another PCI-Ex to sata card where you can plug in the Blu-ray drive may be a good solution but you still won't be sure that with this new card the player will be detected as a boot drive which I think is the most important thing. The other problem (the Blu-ray drive being detected as a removable device) can be fixed by applying the solution suggested by @jaclaz (tested and working).

 

If I didn't look wrong, I read in your motherboard user manual that there are two options in the bios: "Option ROM Scan" and "ROM Scan Ordering".
In order to get the Blu-ray player connected to the asmedia card as a boot device, do you have already set the first option on "Enabled" and/or the second on "Add-On first"?

I'm asking just to make sure we've tried every possibility for your motherboard.

[Andalu]

@Dave-H

I just saw that the errors are XP-related and I assume they were detected by chkdsk during booting with the GPT disk already connected to the asmedia card.

Since XP does not officially support GPT disks and the way to get them recognized is to be considered a workaround, I guess it is normal not to be able to expect that even disk tools like chkdsk can work properly.

The chkdsk control during the XP boot can be disabled by modifying the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

changing the value data to

autocheck autochk /k:drive letter *

In your case it must be:

autocheck autochk /k:T *

 

A still unsolved problem is the one I reported here. I have not yet been able to figure out under what circumstances it occurs.

 

[jaclaz]

I don't like that CHKDSK report.

Besides and before the actual errors, WHAT (the heck) is using the volume?

Quote

Checking file system on T: The type of the file system is NTFS. Chkdsk cannot run because the volume is in use by another process. Chkdsk may run if this volume is dismounted first. ALL OPENED HANDLES TO THIS VOLUME WOULD THEN BE INVALID. Would you like to force a dismount on this volume? (Y/N) Volume dismounted. All opened handles to this volume are now invalid.

Personally I would still have a first partition within the first 2.2 TB (and use ONLY that one in XP), the 32-bit limit is inherent in the "storing" of the partition data in the MBR style of partitioning but we don't know if any "limited to 32 bit LBA addressing" math operation is in any of the drivers or tools.

The experiment to do is anyway:

1) repeat the backup/whatever operation that triggered the behaviour (in Windows 10)
2) unmount/disconnect and re-mount/re-connect the disk under Windows 10
3) run a CHKDSK manually under WIndows 10 (without any parameter)
4) if there are NO issues, reboot to Windows XP
5) if the CHKDSK is not automatically started, run it manually (again without parameters)

jaclaz

 

[Dave-H]

10 hours ago, Andalu said:

@Dave-H

were the errors detected by chkdsk in XP or in Win10?

 

Your idea of getting another PCI-Ex to sata card where you can plug in the Blu-ray drive may be a good solution but you still won't be sure that with this new card the player will be detected as a boot drive which I think is the most important thing. The other problem (the Blu-ray drive being detected as a removable device) can be fixed by applying the solution suggested by @jaclaz (tested and working).

 

If I didn't look wrong, I read in your motherboard user manual that there are two options in the bios: "Option ROM Scan" and "ROM Scan Ordering".
In order to get the Blu-ray player connected to the asmedia card as a boot device, do you have already set the first option on "Enabled" and/or the second on "Add-On first"?

I'm asking just to make sure we've tried every possibility for your motherboard.

Chkdsk has not been running automatically.
That particular instance was after using the disk in Windows 10, and then booting into Windows XP with the disk still connected.
Chkdsk did not run on boot, but I immediately got error balloons in the system tray saying that files on T: were corrupted, and telling me to run chkdsk.
That readout was the result. There had been no sign of errors when I left Windows 10.
I will check that BIOS setting. It's certainly at the default setting, because I've never changed any of those parameters.

[Dave-H]

2 hours ago, Andalu said:

@Dave-H

I just saw that the errors are XP-related and I assume they were detected by chkdsk during booting with the GPT disk already connected to the asmedia card.

Since XP does not officially support GPT disks and the way to get them recognized is to be considered a workaround, I guess it is normal not to be able to expect that even disk tools like chkdsk can work properly.

The chkdsk control during the XP boot can be disabled by modifying the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

changing the value data to

autocheck autochk /k:drive letter *

In your case it must be:

autocheck autochk /k:T *

 

A still unsolved problem is the one I reported here. I have not yet been able to figure out under what circumstances it occurs.

 

Chkdsk is not running automatically on either OS.
Could that be because it's being seen as a removable drive, although I wouldn't expect that to make any difference?
I'm wondering whether to change the XP driver, and use the one provided with the card.
You said that it should still work.

[Dave-H]

55 minutes ago, jaclaz said:

I don't like that CHKDSK report.

Besides and before the actual errors, WHAT (the heck) is using the volume?

Personally I would still have a first partition within the first 2.2 TB (and use ONLY that one in XP), the 32-bit limit is inherent in the "storing" of the partition data in the MBR style of partitioning but we don't know if any "limited to 32 bit LBA addressing" math operation is in any of the drivers or tools.

The experiment to do is anyway:

1) repeat the backup/whatever operation that triggered the behaviour (in Windows 10)
2) unmount/disconnect and re-mount/re-connect the disk under Windows 10
3) run a CHKDSK manually under WIndows 10 (without any parameter)
4) if there are NO issues, reboot to Windows XP
5) if the CHKDSK is not automatically started, run it manually (again without parameters)

jaclaz

 

I suspect that, at least on Windows 10, it's being used by Windows Search.
It's not included in Windows Search on XP though, so that is a bit of a mystery.

If I do make a 2TB partition which can be seen normally in XP, can I then make another 1TB partition in Windows 10, which will only be seen in Windows 10?
It still has to be a GPT disk I assume?

I will certainly be doing the tests you advise, as I do need to know exactly what is corrupting the file system.

 

[Andalu]

3 hours ago, jaclaz said:

the experiment to do is anyway:

1) repeat the backup/whatever operation that triggered the behaviour (in Windows 10)
2) unmount/disconnect and re-mount/re-connect the disk under Windows 10
3) run a CHKDSK manually under WIndows 10 (without any parameter)
4) if there are NO issues, reboot to Windows XP
5) if the CHKDSK is not automatically started, run it manually (again without parameters)

jaclaz

 

I just executed the experiment you suggested with a GPT disk connected to the internal sata port of the asmedia PCI-Ex to eSATA card for both Win10 and XP.
The only difference regarding the point 1): I used a GPT disk initialized in Win10 but with all files copied in XP from another GPT disk.

2) unmount/disconnect and re-mount/re-connect the disk under Windows 10:

3) run a CHKDSK manually under WIndows 10 (without any parameter):

4) if there are NO issues, reboot to Windows XP
No chkdsk during the boot

5) if the CHKDSK is not automatically started, run it manually (again without parameters):

 

To run the chkdsk tool without getting the message "the volume is being used by another process," it was necessary to close the handle related to the GPT disk for the explore.exe and mmc.exe processes.

I also received the same message from chkdsk "windows found problems with the file system" with another GPT disk when disconnected from the asmedia card in Win10 and reconnected to the same card in XP.

Edited February 20 by Andalu

[jaclaz]

Yes, make a normal GPT style disk.

The first partition (within the 2.2 TB) will be seen by XP AND it can be used by both Windows XP AND Windows 10.

The second partition (beyond the 2.2 TB) will be seen by XP as well, only don't use it for writing when under XP, or you could decide (under XP only) to remove the drive letter assigned to it.

Though whether it will make any difference with NTFS/$MFT errors is to be seen.

jaclaz

[Andalu]

3 hours ago, Dave-H said:

Chkdsk is not running automatically on either OS.
Could that be because it's being seen as a removable drive, although I wouldn't expect that to make any difference?
I'm wondering whether to change the XP driver, and use the one provided with the card.
You said that it should still work.

All asahci32.sys driver versions should work with the asmedia ASM1061 card in XP, from the first v1.1.7.110 to the last v3.2.0.
I would try installing v1.1.7.110 also in Win98 if only to leave no stone unturned.

Please consider that each driver should give a good result for the GPT disk recognition but with differences for the safely remove feature. For example, it is not available in the v3.2.0 on the asus Z790 (I have to use the HotSwap! utility) while the dvd-rom drive is still recognized as removable drive.

[jaclaz]

@Andalu

In your case, whatever issue(s) CHKDSK detected (and corrected when running with the /F parameter) seems to be "trifling" (they are not even listed, unlike the ones Dave-H got).

They appear (at first sight) more like something (minor) different between XP and 10 versions of NTFS, in the case of Dave-H, which seem all related to cross-linked files/clusters.

There is a "strange" KB/doc by Paragon:

https://kb.paragon-software.com/article/1004

that essentially states that XP CHKDSK is more "rigid" than later OS version, maybe this is part of the issue.

jaclaz

Edited February 20 by jaclaz