jaclaz

There are more than these, including a few Commercial tools that claim to be able to convert back from dynamic to basic, among them there is partition Wizard 4.2 (free version): https://www.sevenforums.com/tutorials/26829-convert-dynamic-disk-basic-disk.html But I wouldn't trust any automated method and would like to see what is actually on the device. The differences between a (MBR style) dynamic disk and a basic disk (single device, i.e. simple not spanned) are trivial and can be fixed in no time: 1) partition ID in the MBR (42 vs 07) 2) excess sectors at the end of the disk (LDM database) so a quick edit with TinyHexer or similar wouldn't be a problem, but here there is the issue of the Disk seen as invalid (before the "missing" volume). I suspect that here the issue could be that of a conflict between the dynamic disk data and the GPT (second copy of) partition table, but the RAID reference is perplexing. So before attempting a cure, I would like to diagnose the illness. jaclaz

You can use Qemu for running Windows 98. Qemu (there are Windows ports) is however a bit complex to configure/set the right command line parameters. You can try (but no guarantee it will work on your Windows 10) the good ol' Qemu Manager that can still be obtained via the Wayback Machine, Qemu Manager offers a graphical (and very convenient) interface to the VM: http://web.archive.org/web/20120607071209/http://www.davereyn.co.uk/download.htm http://web.archive.org/web/20120506095037/http://www.davereyn.co.uk/qem/setupqemuk70.exe or http://web.archive.org/web/20120506093950/http://www.davereyn.co.uk/qem/qman70.zip If you are OK with a command line only tool, you can get recent Qemu ports here: https://qemu.weilnetz.de/ jaclaz

WinsetupfromUSB is basically meant to setup winnt from USB, NOT boot an XP from USB and though it can be used to install an XP on a USB it is a dual stage procedure, see FAQ #7, point #4 here: http://www.winsetupfromusb.com/faq/ You can however use it to boot a PE (either a PE 1.x, i.e. based on XP, like a BartPE, or a later version), compare with FAQ #1 here: http://www.winsetupfromusb.com/faq/ It is not clear what you mean by a "XP PE", a PE 1.x would normally use SETUPLDR.BIN (and not NTLDR) jaclaz

@cdob I wouldn't worry about that as well. In the worst case (mainboard failure), to recover/access data one can always [1]: 1) make a GPT partition table 2) correct sector/cluster size in the NTFS PBR 3) access the volume from a later OS that undestands GPT or use the Paragon GPT driver on XP (if applicable, would need to be tested) or : 1) use the disk in an external USB case that does 4096 bytes translation 2) correct the MBR and NTFS PBR (more or less what is done in the mentioned thread about switching between 512 and 4096 bytes sector, that approach needs a complicated partitioning scheme to allow for the automatical switch, but manually it is not an issue at all to change a few bytes in the MBR and PBR) I will re-state (if it was needed) that filesystem access is based on clusters and as long as the clusters are the (regular for a NTFS volume of that size) 4096 bytes (i.e. a multiple of *any* physical sector size possible) everything can be "fixed". The issue may come if the cluster size is smaller than that, i.e. 2048 bytes (but i believe it would have needed to be "forced" when formatting), then using the GPT approach is the only way to access the whole volume (through 512 bytes/sector). Anyway, if I were Snear, I would re-create the partition with the "new" 2048 sectors-before paradigm (or 64 or 128, etc.), which is more suitable to a 4096 physical sector and (normally) 512 bytes logical sector disk, and that could make it a tad bit faster in use. jaclaz [1] actually, once said that very few things are as ugly as a hybrid MBR/GPT disk, I see nothing preventing the creation of the GPT structures even now and test the disk connected "normally" (i.e. exposing 512 bytes sector) on a later OS, let's say 7, if the structures are present, changing the involved data (partition table entry and geometry data in the PBR) is just a bunch of bytes and this way one would have a tested "way out" solution in case of disaster.

I.e. like *any* AF disk around, nothing "new" or "peculiar". @daniel_k Good , and interesting links , still none of those shed any light if this is a feature of the specific chip/chipset (triggered or not triggered by this or that driver version) or if it is a feature of this (but not that) driver version (and thus can - at least in theory - be replicated in other drivers). Maybe - just maybe - it is possible to have a "filter driver" (not entirely unlike - say - cfadisk.sys or dummydisk.sys or karyionix's diskmod.sys) capable to replicate the behaviour on other controllers. jaclaz

Good, thanks . In the meantime, I found version 3.1.1540.68 (if needed/for testing) in an archive on driversguide ATI_SB700_IDE_Floppy.zip, I am attaching it. Maybe - just maybe - having a number of "near enough" versions someone with the right knowledge of capability (as an example daniel_k ) may be able to understand what exactly makes these drivers so special, though we don't know if the "variable sector size" is something that is in the driver only or if it is a specific feature of the actual controller chip and the software only "switches modes". A (hopefully "pristine" and unmodified) version 3.1.1540.86 can be found on Acer's site, as a driver for the model Aspire 4535G: https://www.acer.com/ac/en/ID/content/support-product/1141;-; jaclaz ATI_SB700_IDE_Floppy.zip

So, none were included in MS XP SP3? There are - here and there - reports that V3.1.1540.25 is very slow, so, if the V3.1.1540.86 works (and works fast) it should be the "recommended" version. Any source (besides the Dell OEM XP Pro install CD/DVD or *wherever* you found it)? @daniel_k What does NAPA series mean? As a personal favour (only if you wish, of course ): Please, please, please, do not use the .rar format as it is NOT a "universal" format, a lot of other tools (but WinRar) have issues with it. jaclaz

Thank you , re-edited, hopefully this time getting it right, my previous post. jaclaz

The report seemingly mentions using the built-in MS driver (or maybe it is another AMD driver, this is what is not entirely clear), and - still if I get this right ahcix86.sys V3.1.1540.25 works ahcix86.sys V3.1.1540.86 (included in SP3) works or does NOT work? ahcix86.sys V3.1.1540.127 (newer) does NOT work and cannot be even installed ahcix86.sys V3.2.1540.35 does NOT work ahcix86.sys V3.3.1540.29 does NOT work I re-edited my previous post to underline that at the moment that the source could be either MS or AMD. Let's wait for Snear to confirm the above and/or post a more ordered list of what works/doesn't work and the actual source of each file. Once we have a definite list, we can pass the info to Fernando (who is AFAIK the most knowledgeable about SATA/AHCI and RAID drivers ): https://www.win-raid.com/t3024f45-Guide-Integration-of-AMD-s-AHCI-RAID-drivers-into-a-WinXP-W-k-CD.html he may well know much more than us on the various versions. jaclaz

Why would you need a Secure FTP server on an intranet? Wouldn't a "normal" FTP one do? Just in case: https://www.ferrobackup.com/map-ftp-as-disk.html http://www.killprog.com/fdrve.html And also with built-in features in XP: http://cybernetnews.com/cybernotes-map-a-ftp-to-a-drive-in-windows/ jaclaz

So, the 2048 geometry is automagically generated by an original MS (or AMD) driver (though in a couple specific versions only), right? The results of your (nice ) experiments mean in a nutshell that it is possible to "overrule" an exposed device geometry through a driver, I actually suspected something like that since the time the VSS virtual disk driver was found: http://reboot.pro/topic/6492-virtual-storage-driver/ (that driver allows to create virtual disks with either a 512 or 4096 sector size) but I thought that the feature was possible only because of the "virtual" nature of the (simulated) hardware. It should also mean that the good MS (or AMD) guys decided to keep this piece of info for themselves, most probably choosing the easier (please read as lazier) approach that would not create compatibility issues, which might be a "reasonable" choice for external devices (USB disks) that by definition are removable/exchangeable but that sounds like being overcautious for an internal device. jaclaz

Yep, I can confirm vcopy (actually Verbatim copy, I knew it with this more descriptive name) is a very nice tool, useful in a number of situations. As a side note - talking of copying files in a "proper" way - there is - generically speaking - a lack of tools capable of dealing with "sparse" files, or at least they are not easily findable. just in case I put together some of them (which I found "here and there" ) in a post on reboot.pro, here: http://reboot.pro/topic/20487-any-tut-on-expanding-c-partition-on-many-ramdisk/?p=192898 jaclaz

Good to know. And good to know that someone else (as compared with): http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml made the "right" thing, which is that of being able to open a command prompt in the current directory, compatible with the (stupid BTW) elevation of newer NT systems. jaclaz

Yes and no (about bootability/readability). Bootable it won't be (in BIOS), the issue here is - besides the sector data "sensed" (and *somehow* translated to 2048 bytes) that the actual MBR code is "hardcoded" to 512 bytes/sector and will simply fail. (which does not mean that it is possible - in theory - to write a specific/special MBR code, but IF - as it seems - the magic translation is in one of the Windows drivers, it has to be seen - at BIOS level - which sector size is actually seen). Later (when you will have made all the experiments in "non bootable" mode) we can see what happens at BIOS level using grub4dos. Readability in Linux might instead be possible, the MBR - as said and as seen in various experiments with 4096 bytes sectored disks - is "sector size agnostic" (or - if you prefer - there is no field anywhere to specify the sector size at MBR level and 512 bytes is assumed by everyone) BUT the filesystem (be it NTFS or not) has a field for sector size, so at that level it is well possible to have a non-512 bytes/sector perfectly readable, in the end it depends whether the Linux NTFS (or other filesystem) driver: 1) is written "properly" and takes the sector size field into account 2) can (the actual OS) mount the volume as "superfloppy" (i.e. bypassing the MBR, mounting the partition/volume only) In a similar (but actually completely different) situation I devised a (half-@§§ed but working) special formatting scheme allowing to "switch" a same disk between 512 and 4096 bytes sector, the case was an external case with both a USB and an e-sata connection where one of the interface exposed one sector size and the other the other, here: The same approach (if only condition #1 above is fulfilled) could be adapted to this case (and it should/could work both under Linux and on other NT based OS, though unfortunately most probably not under XP if the volume is over the same classic 2.2 TB "limit"). jaclaz

To be fair, Dibya never said Christmas of which year ... jaclaz

Yes, some BIOSes (particularly those of nootebooks/netbooks) have not such an option, you are locked into an UEFI only system. Which wouldn't be in itself such a bad thing IF the "standard" actually was "sane" (it isn't) AND IF it was in itself backwards compatible with BIOS (again it isn't). Maybe however (it depends on a number of factors) it could be possible to make the actual Paragon CD/DVD UEFI bootable, but cannot really say. jaclaz

It depends on a number of factors, as said there are several ways to use Ghost and some values - notwithstanding the use of the word "clone" - may not be the same on the "copy". As an example only (i.e. not necessarily what happened in your case) by definition there cannot be at the same time on a same Windows NT system two disk drives connected with the same Disk SIgnature, if - for any reason - this happens, the NT OS will immediately (and silently) changes one of the two to a new value. If *anything* in the boot process relies on such data, the disk drive won't ever boot until either the Disk Signature is reverted to the original value or the *whatever* is updated to reflect the new Disk Signature. But - back to the issue at hand - generically you had a 0XC000000e error coming in the early stage of booting from BOOTMGR. The problem very likely comes from some of the settings in the \boot\BCD. So the "usual" recommended fix is to run bootrec.exe with the switch /rebuildbcd, but the bootrec.exe is only available (normally) on the install CD/DVD or in the WinRE (the Recovery Environment that may - or may not - have been installed on a given machine). But - besides bootrec - there are other tools that can be used, namely: 1) bcdboot 2) bcdedit the above are included in a "normal" Windows OS, and - actually recommended : 3) BootIce a freeware third party tool that is GUI and is easier to use than the previous two: http://reboot.pro/topic/21956-bootice-v1332/ that can - besides editing an existing BCD or creating a new one - also allow to "fix" other possible issues (such as MBR or PBR missinf/corrupted, change active partition, et similia) Anyway all three need a minimal amount of knowledge on the way the BCD is structured. If you look on youtube there are a few tutorials for how to use bootice in these (and other) cases. jaclaz

Well, you need first a primer on how (since Vista) a NT system boots, and the further changes in 7. In Windows 7 the normal setup creates two partitions (both in MBR and GPT style disks): 1) the "system reserved" one, that is active and gets NOT a drive letter when the system is booted <- this one is called "System" by Microsoft and "Boot" by everyone else 2) the "normal" one containing the actual Operting System <- this one is called "Boot" by Microsoft and "System" by everyone else See: http://www.multibooters.co.uk/system.html http://www.multibooters.co.uk/articles/windows_seven.html The "system reserved" partition in a MBR style disk is marked "active" and contains only: 1) the BOOTMGR 2) the \boot\BCD file 3) some other (mostly language files) Allow me to doubt that you had at any moment two partitions active, as this is - besides not allowed - almost impossible to obtain with *any* "Normal" tool To recap: 1) the "System reserved" partition needs to be active AND it must contain the file \BOOTMGR and the \boot\BCD You can via disk manager or disk part assign temporarily a letter to it (when it is attached via USB to the other Windows 7 machine) in order ot check the contents of the (cloned) System Reserved partition. or you can "flatten" the clone by simply copying to the root of the "normal" partition the contents of the "System Reserved" one, and make this latter partition active (this way you will have a "single partition install", not much different from a typical good ol' XP one. Then it will either work or provide a different (hiigher level) error (like the 0XC000000e you mentioned that comes from \BOOTMGR or \boot\BCD), right now the "bootmgr is missing" comes from the bootsector/PBR of the *whatever* partition is active. jaclaz

Well, AFAICR Ghost has more possible settings/parameters than stars in the sky, so you should post which ones you currently use (that fail) and also some details on how (EXACTLY) the windows 7 system you want to "clone" is configured (like Bios/Uefi, reserved partition or not, which bootmanager - if not BOOTMGR - is involved, etc., etc.). jaclaz

Maybe a BIOS vs. UEFI issue? If you are running windows 10 you are probably also using an UEFI system and all the (BTW stupid) complications connected to it, whilst the CD/DVD may be suitable to boot only on Bios (or CSM in UEFI). jaclaz

Good. The mbr is fine. In the MBR the partition entry is (lba) 63-2441879937, and the 2441879937=0x918C2181 is compatible with the "number sectors" of 0x918C2180 that is in the output of "fsutil fsinfo ntfsinfo" (the excess sector is the $BootMirr which is inside the partition but outside the volume). Now, 5 TB are roughly 5,000,000,000,000 which divided by (2441879937+63)=2,441,880,000 makes 2047,60 which is evidently 2048 bytes/sector (and there may be a few excess sectors after the partition, so it is not possible to calculate exactly the capacity from these data) . About the "fsutil fsinfo ntfsinfo" it has been modified in later OS version (I seem to remember from 7) to display some slightly different info, if you can you could try a later version that has the distinction between physical sectors and logical sectors, *like*: https://docs.microsoft.com/en-us/windows/win32/w8cookbook/advanced-format--4k--disk-compatibility-update You could run ntfsinfo by sysinternals (don't worry the 32 bit version runs on XP just fine): https://docs.microsoft.com/en-us/sysinternals/downloads/ntfsinfo so at least we'll have the data directly in decimal. So that disk seemingly exposes 2048 bytes per sector (but it cannot be the disk if the same disk on another PC doesn't), so it must be something in the drivers on that specific OS instance/install , but I wonder what could cause that. I mean, if you installed some "special" tool and you cannot remember, it must still be there and it should be possible to find it (but it would be queer that it is the "intended effect" of a "special tool", as by now, half the internet would be talking about it) so it is maybe a "side effect" of "something" (yes, not a very accurate definition I know) . jaclaz

"fsutil fsinfo ntfsinfo" And you posted everything BUT the output of that command. 2048 or 1024 make no sense (talking of sector size) maybe what you got is another piece of data, size of cluster, not size of sector or maybe something else?. Besides posting the actual output of that command, post the partition table of that disk, that is the easiest way to check the data. jaclaz

Only for the record (since the given link is also for CMD.EXE and 2K/XP), ALL those are - if not "wrong" - "inferior" to this nice shell extension: http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml jaclaz

Yes, that kind, actually the common ones are coloured, example: https://www.startech.com/eu/Cables/Serial-Parallel-PS-2/PS-2-Cables/6in-PS2-Keyboard-Mouse-Splitter-Cable-Adapter~KYC1MF Green by convention is mouse, purple by convention is keyboard. The issue is that they may (or may not) work on a given motherboard. , it depends on the specific way it was cabled, see: https://en.wikipedia.org/wiki/PS/2_port the port on the motherboard may be cabled/designed for "dual PS/2" or for "normal, single PS/2" no way to know, and - to further complicate the matter - I believe that even splitters are not all the same. jaclaz

Semi-random idea, but if Ps/2 works fine, have you tried IF (no guarantee) a Ps/2 mouse/keyboard splitter works? jaclaz