Yes, a partition table can be recreated.
Yes, a partition table can be recreated.
This is a total shot in the dark, but many years ago I managed to corrupt the file index of a drive on Linux, but a Windows machine was able to rebuild the index and make the drive usable again. There's a chance plugging it back into a Windows system might repair the partition table. I hate to hit you with the "just chkdsk, bro" answer but that genuinely did solve my very similar issue in the past.
I value the prompt reply and attempted to reestablish connection with Windows, though I didn’t proceed much deeper since I wasn’t certain how to resolve the issue. It isn’t assigned a drive letter, which prevents running chkdsk. Do you know any method to force Windows to allocate a drive letter? I suspect this might be limited because there’s no available mount point without the partition table, and I’m beyond my usual technical expertise. [EDITED "to" above]
It seems the system has gone back to GPT Protective Partition. You might try drive recovery tools to try and restore the files moved from your Windows hard drive—this has helped me before. Avoid recovering to the same drive, as it could overwrite the data you want to recover. I’d suggest installing CrystalDiskMark and assessing the HDD’s condition, since proper ejection shouldn’t occur if it does. Would you like me to walk you through opening CMD as admin and using Diskpart? Also, could the drive still appear as a volume even with severe corruption?
I found another helpful guide and gathered more details. After going through the steps you suggested, I identified images 6 and 7. Image 7 was created after testing the other two "NO MOUNT POINTS" volumes, which likely contain boot or recovery partitions for the Windows boot disk. It seems the filesystem is FAT32, which I recognize as problematic since some files exceed the 4GB limit for that format—this is why I opted for exFAT. Following your advice, I downloaded and used Recuva, which revealed that the volume IDs in image 7 were actually incorrect. All three IDs from mountvol corresponded to the boot drive and two recovery partitions. In Recuva, I saw four numbered IDs labeled "HarddiskVolume," but I encountered an error stating "Unable to determine file system type." I also tried running DiskPart and using the "list volume" command, but no volumes appeared (see image 10).
It's quite unusual. I'm not sure what to do next. With Recuva, you might be able to retrieve your files from the original drive—you mentioned you kept them there before transferring them. Try scanning the disk where those files were stored with Recuva. Smaller files, such as photos, usually recover more easily. If that doesn't work, professional data recovery could be necessary.
I'm sorry for the sudden radio silence. I got really tired and went to bed. Tomorrow night, I'll test Recuva on the files to see what I can recover (thanks for the suggestion!). Regarding professional data recovery, do you have any suggestions for contacts or services?
Pickles von Brine could be the one. DriveSavers also comes to mind.
Use Linux to format the drive and ensure readability. Run Recuva with deep scan for recovery. The process may take time, but you can retrieve some files. Even after formatting and losing backups, it worked for me—recovered only the files that were overwritten. For the future, consider purchasing small NAS devices and connecting an NFT drive to store important files securely.
For Linux my top disk manager is KDE partition manager. I managed to recover quite a bit—most photos, videos, and a few documents. You can check if you haven’t overwritten anything by seeing if the files are still intact and haven’t been touched. This happened due to an accidental partition deletion. I reformatted the same filesystem, but I’ve stopped adding any new files to the drive. Windows might still write temporary files, which could overwrite some data but not everything. Hope you have a larger secondary drive ready to store all recovery files. Once it starts booting with Linux, it may take a while because the system will attempt to read the disk again and keep trying until it succeeds.