Andalu

I have done a test to check the behavior of the Paragon GPT Loader driver with the 2TB limit in an XP system configured in IDE mode. After formatting my 4TB Seagate ST4000LM024 GPT disk in Win10, I started to fill it always in Win10 by copying in a progressive way the files numbered from 01 to 432 until to reach 2,194,897,825,792 bytes (at the end of the copy I made sure that all the files were uncorrupted): After connecting the disk to the XP system with Paragon GPT Loader installed, I first verified again that all files were not corrupted and then copied a single file to the disk reaching a total of 2,199,889,600,512 bytes: Checking once again the integrity of all files, I noticed that the first file copied a few days earlier (the one marked with the number 01) was now corrupt while all the others were intact. But on the next system reboot, here is what happened: The problem encountered is almost the same as the one I detected using the asmedia asahci32.sys driver in a system configured in SATA/AHCI mode. The difference, which is no insignificant, is that at least with the asmedia driver, by following the identical procedure above, the drive was still accessible in XP and other files were still correctly available although the 2,199,023,255,552 bytes limit was exceeded. At this point, I also have serious doubts whether the GPT Loader can effectively work on 3TB GPT disks. It certainly does not work on 4TB GPT disks.

@roytam1 None of the storahci.sys drivers known to work in XP allow recognition of GPT disks. Tried after installing the GPT_Loader with both storport.sys from Win7 (disk not even listed in Device Manager) and storport from Win8 (disk listed in Device Manager but no volume detected). Same behavior even without installing the Paragon driver.

There are versions ported from Win8 (storahci.sys v6.2.9200.16384 and storahci.sys v6.2.9200.20652) but I actually don't remember testing them with the GPT Loader. I will give them a try.

Thanks for the confirmation. Unfortunately, even with drivers that do not depend on scsiport.sys you cannot get recognition of GPT disks even if you have the GPT Loader installed in a system configured in AHCI mode. The only sata/ahci driver that allows recognition of GPT disks on intel systems even without GPT Loader is the asmedia asahci32.sys. But it, too, is based on scsiport.sys which is thus the reason for the problem of corrupted files I encountered on disks with sector size of 512 bytes when the limit of 2,199,023,255,552 bytes was exceeded.

When you write that any driver that uses SCSIPORT.SYS does not work well are you referring to some limitation that the latter has? Maybe the one of 2,199,023,255,552 bytes with disks that have a sector size of 512 bytes?

@Dave-H I don't remember exactly where I got it from, @roytam1 is probably right or maybe it is a simple renaming? Edit: I just downloaded the version you uploaded some days ago and it is identical (same SHA-1) to the gptmount.sys I used in my test. [off-topic]: @roytam1 I take this opportunity to thank you for the wonderful work with Basilisk

According to the thread title, here we are talking about GPT disks to be recognized in XP in order to have more data space available than the 2.2TB MBR limit and to have the possibility to use the same disks in operating systems later than XP. I have not yet thoroughly tested the Paragon driver but from the minimum I have been able to observe it does not seem to emulate any other disk. I have tried all the sata/ahci drivers known so far to be compatible with XP and with none of them does the Paragon driver allow recognition of GPT disks.

@user57 More than firmware, I think it is a driver question, as for the Paragon GPT Loader mentioned above. In this case, it would be a matter of modifying the driver so that it recognizes GPT disks even in motherboards that have only the SATA/AHCI option in the BIOS, as in the case of older ones that also provide IDE mode, for which such a driver seems to work without problems even when the data written exceeds the 2.2 TB limit as reported above by @aoresteen (I have not yet tested). Could you do that?

I did not understand what you are referring to. Could you please explain further?

I have never tried and I think I am unlikely to do so, both because I do not have a compatible drive and because I think it is preferable to avoid the risk of ending up with a damaged hard drive.

@Dave-H I tried the Paragon driver on my MSI Q87M board, which has the option of selecting either IDE or AHCI mode in the BIOS. As I feared, I got confirmation that the GPT Loader allows recognition of GPT disks in XP only in IDE mode: while that driver fails when AHCI mode is selected. Here is the image for the GPT Loader installed on the same MSI Q87M board: Unfortunately, more modern components do not always allow better possibilities (and in some aspects not even better performance).

@Dave-H Thank you for all the information. I have the same version of the Paragon driver. From what I see in the image the driver installed on your system should be the one that supplied with the CD that is bundled with the motherboard or at least the one available on the manufacturer's site as compatible with your board. For several of my motherboards, however, there are no XP-compatible drivers, and those that can be installed do not appear to be compatible with the GPT Loader. If I remember correctly, only one that I still have somewhere has the option of setting IDE mode in the bios. Maybe I will give it a thought and restore it to try the Paragon driver. Just out of curiosity and you will excuse me for being so insistent: in the Device Manager, under IDE ATA/ATAPI controllers, could you please right click on Intel(R) 631xESB/6321ESB/3100 Chipset Serial ATA Storage Controller-2680, choose Properties -> Driver -> Driver Details and post the driver name and version? Thankssss

@Dave-H Thank you. What is missing is the info about the SATA or IDE driver that is installed in your system. It may be that the failure of the Paragon driver to recognize the GPT disks in my systems may depend on that. P.S.: I already have the Paragon driver.

Good! What is the driver and what version do you have installed for the internal sata or IDE controller? Could you please also report the specs of your 3TB GPT disk that can be obtained through the command fsutil fsinfo ntfsinfo in the Win10 command prompt? Thanks!

@Dave-H With the Paragon GPT Loader driver installed, does your system detect the 3TB disk as a GPT drive?

Good to know that in your case Paragon GPT Loader worked. Here it has never worked in any of my systems. It would be interesting to know what motherboard you installed it on, whether it has intel or amd or other controller, the type of controller (sata or IDE) on which XP is installed, and, if possible, the specs of your 3TB disk (which can be obtained in Win10 with the command "fsutil fsinfo ntfsinfo") to have some chance to figure out why the Paragon driver did not work on my systems and whether it can also work for disks larger than 3TB. I really hope to get the Paragon driver working properly on my systems as well, so that I can realize that the 2TB limit in GPT disks can be exceeded through the use of a disk driver.

In my case that did not happen: in my latest tests I copied video files (it is easier to check them) in successive stages in both Win10 and XP and at the end of each copying stage I always checked the integrity of the files in both operating systems without finding corrupted files until I exceeded the limit of 2,194,701,336,336 bytes. Copying a few more GB beyond this limit, I found that some files copied in the early stages were now corrupt.

I was misled by the fact that copying files beyond 2TB was going smoothly and that checking via chkdsk in both XP and Win10 had never reported anything unusual. Moreover, even though the total amount of data copied to a GPT disk had exceeded 2TB (2,963,807,977 bytes), all files were still correctly listed in Windows Explorer. Only later, after @Dave-H's reports, did I discover that some video files copied at earlier times were no longer playable because they were corrupted. Quite a catch

Thanks to the asmedia asahci32.sys driver together with the disk.sys and partmgr.sys drivers from W2K3, a GPT disk is detected in XP in its full size and can also be formatted, as shown in the following image: The problem, unfortunately, remains that you cannot use the space above 2TB because writing beyond that limit will result in corrupted files.

@pappyN4 Hi, thanks for the advice, but formatting the GPT disk in XP -> Disk Management did not work: even in this case, the first file copied on the disk immediately became corrupted as soon as the 2.2 TB limit was reached. But unlike what happened in my previous tests performed on a GPT disk initialized by the manufacturer and with other disks initialized by me in Win10, after completing the copy operations and rebooting the system, connecting the disk to the same internal sata port, all the files are now disappeared. As can be seen from the following image, the disk is now seen as both GPT and MBR and also all operations that should be allowed on the partition are now greyed out: The same happens by plugging the disk in Win10. For the other GPT disks tested previously, however, files under the 2.2TB limit still remained visible and fully available in XP. At the moment the possibility of using a GPT disk greater than 2TB in XP seems to be impossible to achieve The only way to be able to use a disk larger than 2TB remains to initialize the drive in MBR style by using the WD Quick Formatter utility, even if only for the external drives.

@Dave-H No good news from here. I tested a new 4 TB GPT disk extracted from a Seagate Expansion enclosure by connecting it to an internal sata port and starting copying files in successive stages in both Win10 and Win2003 until it reached 2,050,490,049,862 bytes and then exceeding this limit by copying more files until it reached 2,459,394,870,229 bytes. In Win2003 I checked every file at the end of each copying step (both those just copied and those already copied in the previous steps) without ever encountering any problem of corrupted files, even when I chose to install the asmedia v2.0.3.1 driver for the intel sata controller. Up to this point, the disk has never been connected to an XP system. Unfortunately, in XP, with the same version of the Win2003 drivers, I did not get the same result: as soon as the GPT disk with the files reaching a total of 2,459,394,870,229 bytes was connected to the internal sata port of the intel controller (for which the same version of the asmedia driver had been installed), without having copied or deleted anything on it, I immediately found that some files were corrupt: their size was identical to that of the original files but the content was different. The total number of corrupted files (all belonging to the folders of recently copied files) was 264,190,679,758 bytes so subtracting it from the cumulative total of all the files (2,459,394,870,229 bytes) gives a result of 2,195,204,190,471 which is very close to the maximum limit of an MBR disk (2,199,023,255,552 bytes)*. But isn't it about a GPT disk? Edit: * with a sector size of 512 bytes.

Hi @Dave-H unfortunately, for the past few days I have been experiencing problems with corrupted files and unreadable folders even on my GPT disks connected to the asmedia card in XP. After reading about the problems you reported in your posts I did a check and realized that for example some video files were no longer playable in both XP and Win10. The strange thing is that in both operating systems, checking with chkdsk via command prompt never detected any anomalies. Since discovering such issues, I have done some tests to try to figure out what they might depend on and at the moment I can say that probably in XP the problem is exceeding the "classic" 2.2TB limit. Today, in a 4TB disk, after verifying that all files occupying a space of 2,198,497,806,087 bytes were without problems, I copied others to it until 2,473,491,444,978 bytes were reached: no problems detected in copying and no problems for both old and new files but only until the next reboot of XP when some old files previously working were now corrupted. I will have to do more tests to be sure of the above and also to be able to figure out whether the anomalies found may depend on the asmedia card and its driver or firmware versions or the disk.sys and partmgr.sys drivers that cannot work in XP as they do in Win2003 (where I did not detect any problem even exceeding the 2.2TB limit) or other reasons that at the moment I cannot imagine what they may be. I will report the news as soon as I have definite information about it. First, I will have to find time to make a new backup of the files that then became corrupt

For XP in FAT32 you need to modify the registry as reported by @Cixert in the following post: https://msfn.org/board/topic/181911-read-gpt-hard-disk-on-windows-xp/?do=findComment&comment=1249360 In step 1. and 2. you will also find the solution to avoid automatic replacement of disk.sys v5.2.3790.4006 with XP version.

@Dave-H This may be another test to try: since in Windows 10 you do not need to install the asmedia driver for the asmedia card because the microsoft one is enough, if no errors are detected for your drives under 3 TB, the asmedia driver may be the culprit. My other suggestion may seem a bit long to apply, but it only takes time to clone the XP disk, depending on the size of the drive. Once you boot the newly cloned XP disk, installing the asahci32.sys driver v2.0.3.1 with the modified .inf file for your motherboard's sata controller is simple and requires only one or two reboots. This is to exclude the possibility that the errors detected on your disks may depend on the asmedia card.

@Dave-H It's really strange what happened for your two drives. I don't have an answer for it. To narrow down the number of items to examine, I can only repeat the previously suggested test (hoping this time to explain it better) that does not involve the asmedia card: - clone the system disk with XP (or install XP from scratch) to a spare disk; - boot XP from that disk (eventually you can insert the drive in the caddy); - in Device Manager, after properly editing the asahci32.inf file (I can send it to you if necessary), install the asahci32.sys v2.0.3.1 driver for the intel sata controller to replace the existing one (its hardware ID begins with PCI\VEN_8086&DEV_XXXX&CC_0106); - restart the system and, if it boots correctly, connect one of the disks to the internal sata port on the motherboard; - start copying the files to the disk via explorer.exe and then run the test with chkdsk. I think that version of the asmedia driver may work successfully on your intel system as well.