Win 10 installed itself on two drives... why?

whisper

Limp Gawd
Joined
Mar 16, 2003
Messages
466
I installed Win 10 on my new build this week, with the intention of having the OS on my Samsung 960 NVMe. However, I also had an empty Seagate SATA 4TB hdd connected to the mobo. I selected the NVMe as the destination to install Windows, and all appeared to proceed normally. I then tried to create a new 4TB partition on my hdd, which of course would require me to convert it to GPT - normally a simple process. To my surprise, Windows had already created a system partition on the hdd which I could not remove (in addition to the files on the NVMe), and the disk could not be converted to GPT.

To get around this, I disconnected the SATA hdd and re-installed Windows on the NVMe. This time it had no choice but to limit the installation to the NVMe itself. Now all's well, but to put it bluntly... wtf??

Why does Win 10 feel the need to create multiple partitions across two disks in order to complete a "typical" installation? How could it possibly be more efficient to have a system partition on a magnetic drive when it obviously can run just fine off the NVMe alone? Seems like bringing the hdd into the loop would just be a bottleneck.

Wasn't sure whether to put this in the data storage or OS area. Just curious if anyone has seen this and if there is a good reason, or just Win 10 being slightly stupido_O
 
The 4TB drive must have been set as the boot drive at the time, even if your older OS was booting from another drive.
Its not an OS issue.
Just adding or removing a drive can cause the bios to change the boot drive without any interaction.
If you ever unplug/replug a drive you should check the bios setup again otherwise an OS repair can really screw things up!

I have seen exactly the same behaviour, my current PC can do it too. (Skylake)
With another drive selected as the primary boot that doesnt have a boot sector or fully functioning boot sector, it can be bypassed and the second drive becomes the active boot drive.
I actually did exactly this a few days ago.
This is why I do as you did in the end, always unplug other drives when installing an OS.
 
It's definately an OS issue. Windows can't handle multiple drives during instannation and you should always unplug all other drives except the boot drive when installing windoze.

If you were installing linux or OSX the setup would have asked you which drive you wanted the install to go to.
 
I installed 10 recently with a similar setup, 960 EVO NVME and 4TB WD Blue, both brand new and unformatted, btw.
I just went into BIOS to make sure the 960 was the first HDD in the boot order, then installed 10.
After 10 installed, I went into Disk Management and initialized the WD Blue and formatted it.

But like everyone said, best to installed the OS with only the OS destination drive hooked up.
I was lazy and the setup was in an SFF case and and hard to get to the cables.
 
The first time around, I set the boot order to 1. USB Key, 2. NVMe, 3. SATA hdd. Basically I just made sure USB key was first because I was booting off the Win 10 USB stick. I'm guessing what happened is that Windows tried to be cute and put files on both the NVMe and hdd, thereby allowing either one to function as a boot drive. Obviously it didn't have that choice once I disconnected the hdd. I still think it's quirky for the installer to make this choice when the user has selected only one drive for installation, but lesson learned. Thanks all!
 
The first time around, I set the boot order to 1. USB Key, 2. NVMe, 3. SATA hdd. Basically I just made sure USB key was first because I was booting off the Win 10 USB stick. I'm guessing what happened is that Windows tried to be cute and put files on both the NVMe and hdd, thereby allowing either one to function as a boot drive. Obviously it didn't have that choice once I disconnected the hdd. I still think it's quirky for the installer to make this choice when the user has selected only one drive for installation, but lesson learned. Thanks all!

I am guessing that the Seagate was already formatted. Did that drive ever have on OS on it?
 
Yep when installing windows unplug every drive you don't intend to install on. If you have backup drives remove them... and for good measure unplug your NAS. lol Seriously windows install has always been terrible for doing what ever the F it likes.
 
Bloody ridiculous.

An OS that refuses to install on the chosen drive and will install across drives as it pleases, and people defend this shit.
 
I am guessing that the Seagate was already formatted. Did that drive ever have on OS on it?
Actually, no, that's what I found strange. It was a brand new drive that I unsealed from the box the same day. Not only did the Win 10 installer create boot files on it, but before that it created a small 500 MB partition which I could later see in the disk management utility. Because it was dedicated to system files it was not possible to remove the partition nor convert the disk to GPT. Only option was to start over.
 
Windows won't do this to an unformatted drive. So if it touched the Seagate, it had a partition formatted already.

That being said, I've never encountered this issue. I always run diskpart from the installer's main screen to check the order and convert my primary to GPT.
 
Bloody ridiculous.

An OS that refuses to install on the chosen drive and will install across drives as it pleases, and people defend this shit.

I actually find this entertaining ;) . And to think of how long ago Windows was made and still it does terribly simple things wrong ;)
 
People who install Linux generally have a pretty solid understanding of what's going on with their computers. So when they install to a drive and it doesn't boot right after, they can troubleshoot.

In addition to Microsoft's history of not recognizing that other OS's exist, Windows users in general don't have very strong problem-solving skills when it comes to their computers. So the installer tries to make sure Windows can boot and will put it's boot files on the drive that BIOS lists as drive 0. The boot order you set up doesn't necessarily determine which drive is 0. Drives are usually numbered in the order they're found during POST. Typically the first device scanned for drives is the chipset controller, then on-board 3rd party controllers, then expansion board controllers (including NVME). For example, my 950 Pro drive is my boot drive, but it's listed as drive 9 because I have all of my SATA ports filled up.
 
I actually find this entertaining ;) . And to think of how long ago Windows was made and still it does terribly simple things wrong ;)
If we're going by age, Linux is older, created in 1991. I'm comparing that to Windows 95, which was the first of the non-DOS based, redesigned Windows versions. WFW and those were entirely different. Given that, and Linux's low adoption rate and lack of user-friendliness, it's isn't a comparison Linux is going to win.

I say this as someone who's actively using both OSes. They both have their strong points and both work very well. Arguing over the two is just pointless.
 
I've had this happen on Windows 7 as well. Regardless of OS now I unplug all but the drive I am installing to.
 
It's definately an OS issue. Windows can't handle multiple drives during instannation and you should always unplug all other drives except the boot drive when installing windoze.

If you were installing linux or OSX the setup would have asked you which drive you wanted the install to go to.

Regardless of what constitutes "best practice", saying that Windows can't handles more than 1 drive during install is wrong. Personal bias doesn't make it fact.

I have installed numerous Windows images with more than 1 drive. This sounds like a bios issue.
 
I understand that this problem does exist, I have seen such a drive letter mismatch when a usb card reader is installed. :D However, I have multiple drives on my two computers and have yet to have this issue occur. Also, I also never had this issue occur on all 4 of the FX series cpu motherboards that I once owned.

I am now using M.2 drives as my primary drives without issue. (One Sata, the other NVMe.) Therefore, at least in some instances, we are seeing a bios level issue.
 
If we're going by age, Linux is older, created in 1991. I'm comparing that to Windows 95, which was the first of the non-DOS based, redesigned Windows versions. WFW and those were entirely different. Given that, and Linux's low adoption rate and lack of user-friendliness, it's isn't a comparison Linux is going to win.

I say this as someone who's actively using both OSes. They both have their strong points and both work very well. Arguing over the two is just pointless.

Windows 95 through ME were all still DOS based.
 
Windows 95 through ME were all still DOS based.
I'd call them redesigned OSes. Previous to 95, you still needed to use a command line for many tasks. 95 brought the first full GUI that didn't require command line usage for your daily tasks. It was there, but one could argue that's still the case in Windows 10.
 
Regardless of what constitutes "best practice", saying that Windows can't handles more than 1 drive during install is wrong. Personal bias doesn't make it fact.

I have installed numerous Windows images with more than 1 drive. This sounds like a bios issue.

Are you kidding?! The issue used to happen under Windows 7. You select the drive Windows is to install the OS to and it sticks the MBR on whatever drive it pleases.

Under Linux the installer on most packaged distro's is easier to use than the Windows installer, it's got nothing to do with skill set. Linux simply obeys your commands and only installs itself on the drive of your choosing. It's the reason why it's so difficult to reliably dual boot Linux with Windows 10.

Had me stuffed years ago. I had drives set up as removable, I'd swap one particular drive for another and all of a sudden the PC wouldn't boot.
 
This happened to me too a while back installing Win10. I've installed Win7 countless of times with multiple drives and never has this problem. I feel like it's intentional on Win10. Maybe it was an attempt to decrease boot times on Win10 by placing a system file on each drive.
 
I have dealt with windows form 7 up trying to fix the MBR of drive zero more then a few times over the years.

As others have said... MS is stupid, windows is stupid. Unplug all your drives, unplug any non-needed usb drives and devices... hell if you want to cut time of your windows installs go into your bios and shut down onboard stuff to. (half kidding there)

Your life is much simpler at that point windows will install where its supposed to... then you can plug things back in and add it to your Linux boot manager.
 
I've seen something like this on past Windows OS's, it put the boot info on a secondary drive; I might have discovered that when swapping the secondary out and finding I could not longer boot.

Now days when I do a new install I just disconnect everything or disable all other drives so I can be sure that Windows puts all OS-related material on the OS drive.
 
Sounds like this is at least a somewhat common problem across multiple windows versions. I checked and confirmed my mobo has the most recent bios from MSI (v. 7A63v15). The simple solution is always to disconnect any/all drives except the one needed to install - should have done that the first time, but won't make the same mistake again. Thanks for all the helpful comments;)
 
Are you kidding?! The issue used to happen under Windows 7. You select the drive Windows is to install the OS to and it sticks the MBR on whatever drive it pleases.

Under Linux the installer on most packaged distro's is easier to use than the Windows installer, it's got nothing to do with skill set. Linux simply obeys your commands and only installs itself on the drive of your choosing.
I haven't seen yet windows OS that installs itself on other drive than the one choosen by user. The other thing is about the boot record and the reason why windows does this is to be as users (unexperienced users that is) friendly as possible. When we mess around with drives, replace and change something later, it can fail, true, but for the most times it works as supposed.

I don't understand, either Linux users are not so well educated or just trolling about it. If you understand how things are working you will never experience such problems. First thing, Windows does obey user's choose of the OS drive. But as I wrote earlier, to be as users (unexperienced users) friendly as possible, Windows makes sure you will have no issues booting in the new OS after installing it (this is what most users aim for). So it checks what drive is set as first/ boot drive in BIOS and if it is not the drive you are installing Windows to, it installs the boot record on the corresponding drive so it can direct to the correct drive with Windows OS when booting up. If not done so, boom, Windows will not boot and most users will not be happy. That was the case on XP, windows 7 and now on Windows 10 too. Is that so hard to uderstand?!!

Secondly, if you want to bypass this, best fail proof (and-not-going-around-messing-with-BIOS settings) method is to disconnect all other drives but I have never experienced such problems when accordlingly setting first drive in bios to be the one you are installing Windows to and setting it as first boot device (or after removable devices).
 
Last edited:
I haven't seen yet a windows OS that installs itself on other drive than the one choosen by user. The other thing is about the boot record and the reason why windows does this is to be as users (unexperienced users that is) friendly as possible. When we mess around with drives, replace and change something, it can fail, true, but for the most times it just works as intended.

I don't understand, either Linux users are not so well educated or just trolling about it. If you understand how the things are done you will never experience such problems. First thing, Windows does obey user's choose of the OS drive. But as I wrote earlier, to be as users (I repeat, unexperienced users) friendly as possible, Windows make shure you will have no issues booting in the new OS after installing it (again, this is what most users wants). So it checks what drive is set as first and boot drive in BIOS and if it is not the drive you are installing Windows to, it installs the boot record on the corresponding drive so it can direct to the correct drive with Windows OS. If not done so, boom, Windows will not boot and most users will not be happy. That was the case on XP, windows 7 and now on Windows 10 too. Is that so hard to uderstand?!!

Secondly, if you want to bypass this, best fail proof (and-not-going-around-messing-with-BIOS settings) method is to disconnect all other drives but I have never experienced such problems when accordlingly setting first drive in bios to be the one you are installing Windows to and setting it as first boot device (or after removable devices).

Mate, I can assure you, I know how to install Windows.

I have had Windows 7 install the MBR on a drive other than the drive that was selected as the OS drive and the drive was not selected as the first boot drive (why the hell anyone would select a drive as the boot drive in UEFI/BIOS when it's not the drive you're planning to install Windows to is beyond my comprehension). Hence, when installing Windows you have to use a retarded work around to stop the OS from using drives the OS isn't instructed to install to. Don't single me out because I'm a Linux user.
 
Are you saying that Windows was installing MBR on a drive not selected as first boot drive and not accesed by any way when booting up the PC? You know, there could be exclusions when you have set first boot drive as number one but still PC (can't think of correct word right now) access other drive at first when booting up. How can it be Windows fault when it detects correct drive that is used when booting up? Now, if for some reasons Windows installed MBR on a drive that is not used by any way in boot process... that would really be weird but even then it does not mean that Windows has a habbit to do it and it will be more like a hardware issue than anything else.
 
Last edited:
Are you saying that Windows was installing MBR on a drive not selected as first boot drive and not accesed by any way when booting up the PC? You know, there could be exclusions when you have set first boot drive as number one but still PC (can't think of correct word right now) access other drive at first when booting up. How can it be Windows fault when it detects correct drive that is used when booting up? Now, if for some reasons Windows installed MBR on a drive that is not used by any way in boot process... that would really be weird but even then it does not mean that Windows has a habbit to do it.

Yes, I am and I've experienced it many times, before the advent of Windows 10 - As stated, the first time I experienced it, it had me stuffed why removing a storage drive rendered the system unbootable when the storage drive was not selected in UEFI/BIOS as any top priority boot drive or selected when installing Windows 7.

I don't know why, but Windows will stick that MBR on any drive connected to the system it pleases.
 
Are you just saying so or you have actually confirmed that before new Windows installation 1) your storage or whatever drive was not holding any boot data and 2) was not envolved in any part of boot sequence before Windows was installed? In that case it seems UEFI/BIOS does not report it's boot order as it should or installer does not interpret it correctly... But still I find hard to believe that Windows randomly will put MBR on any drive whenever it takes part of boot process or not. It's just not what my experience (and common sense) says. Unless it's proven on various different hardware instalations, I find it more like an one time exclussion that common practice.
 
As I said before, the drive you pick in BIOS setup to be the first boot drive is not necessarily the first physical disk 0. Windows doesn't know how to interpret BIOS settings as there's too many different variations of what each bit stored in the 256+ bytes of CMOS ram actually means. So it can't know that you have selected another drive to have priority. Instead, it looks to the ACPI tables that are created during POST. When it sees you're installing to disk 5 and disk 0 is either blank or has a compatible file system, it'll add it's boot information to that drive.

UEFI installs are a little different now that Windows can directly manipulate the boot order stored in NVRAM and just insert it's own boot table entry. But if you add or remove a drive and change the disk order (not boot order), you run the risk that Windows' boot entry no longer points to the same disk.
 
So basically you are saying that the only way to avoid this (other than to disconnect all drives) is to physically connect correct disk to motherboard's SATA0 port? Well I do have 2 ports in MB in black color (in manual written use as data disks) and 4 red connectors (use as system disks) or in verse order don't remember and I always wondered why.... But I do remember clearly few times I have done mistakes and installed OS on another drive while boot drive was set on different drive and all it took to get things right (next time I needed to install OS) was to set in BIOS under Hard Drives - First Drive the one I needed to install Windows on and then on next setting Boot Order it automatically apperead as first hdd drive and had no problems installing on it without changing or removing anything. Perhaps it depends on it how correctly BIOS is reporting it's boot order or whatever and it depends on motherboard manufacturer and what not else. But it is good explanation as to what is happening, thanks.

p.s. and I thought old IDE drive days with the need of setting correct Master/Slave jumpers and pluging accordingly to the motherboard are long time gone...
But if you add or remove a drive and change the disk order (not boot order), you run the risk that Windows' boot entry no longer points to the same disk.
and in that case not only Windows but Linux or any OS will fail to boot, because it is not OS dependent in what drive UEFI/BIOS will look for boot information, right?
 
Last edited:
So basically you are saying that the only way to avoid this (other than to disconnect all drives) is to physically connect correct disk to motherboard's SATA0 port? Well I do have 2 ports in MB in black color (in manual written use as data disks) and 4 red connectors (use as system disks) or in verse order don't remember and I always wondered why.... But I do remember clearly few times I have done mistakes and installed OS on another drive while boot drive was set on different drive and all it took to get things right (next time I needed to install OS) was to set in BIOS under Hard Drives - First Drive the one I needed to install Windows on and then on next setting Boot Order it automatically apperead as first hdd drive and had no problems installing on it without changing or removing anything. Perhaps it depends on it how correctly BIOS is reporting it's boot order or whatever and it depends on motherboard manufacturer and what not else. But it is good explanation as to what is happening, thanks.

p.s. and I thought old IDE drive days with the need of setting correct Master/Slave jumpers and pluging accordingly to the motherboard are long time gone...and in that case not only Windows but Linux or any OS will fail to boot, because it is not OS dependent in what drive UEFI/BIOS will look for boot information, right?

There's no guarantee that SATA0 as marked on the motherboard corresponds to the first place that the BIOS will look for drives. So no, that's a reliable way to avoid this issue.



If the BIOS remaps your drives according to your boot priority.. then where Windows installs it's boot loader should be a non-issue. But there's no guarantee that it'll do that.

On my current motherboard (UEFI), as I've added more drives to my system my boot drive has become disk 8 even though I have it set to first boot in the settings. Fortunately, I haven't had an issue booting because of it.

At the end of the day, Windows is designed for the lowest common denominator to reduce support overhead. Most Linux distros are designed to just do only what you tell it you want to do, regardless of whether you know the consequences of that or not.
 
So we can come to conclusion, that it's not Windows to be blame that it installs randomly boot record where it pleases that or other time but it tries to get from BIOS what hdd will be as first in order to boot and in my case it always does succesfull job, in some cases apperantly not, but again, how it is Windows fault if BIOS 'hides'' it's true boot order.

I didn't mean exactly SATA0 to be always first that BIOS will look, it was just an example, what if it was.... but you answered that about remaping, thanks. I guess that's how all BIOSes should work to give less confussion to the OS's about boot lol
 
So we can come to conclusion, that it's not Windows to be blame that it installs randomly boot record where it pleases that or other time but it tries to get from BIOS what hdd will be as first in order to boot and in my case it always does succesfull job, in some cases apperantly not, but again, how it is Windows fault if BIOS 'hides'' it's true boot order.

I didn't mean exactly SATA0 to be always first that BIOS will look, it was just an example, what if it was.... but you answered that about remaping, thanks. I guess that's how all BIOSes should work to give less confussion to the OS's about boot lol

Linux seems to work it out just fine....

I've encountered this issue under Windows numerous times from Windows 7 onwards, untick 'show hidden files' and you can see the MBR on whatever random drive Windows has decided is best to install the MBR on - I can assure you that before Windows was installed, that MBR was not present on a comparatively slower storage drive.
 
Back
Top