Win10 - setup with 4TB data drive

HCHTech

Well-Known Member
Reaction score
3,824
Location
Pittsburgh, PA - USA
We've got a new build on the bench now that has pointed out what seems like a change in functionality that I'd like to clarify.

So this is a Ryzen 7, Asus Prime450 MB (fully updated BIOS), Samsung NVMe drive for the OS, and a 4TB WD Black for data storage.

In the past, I am sure that we:
  • Assembled the machine with all components
  • Installed Win10
  • Initialized the storage drive as GPT when prompted or in disk manager, followed by a format
  • Finished prep for delivery
With this build, however, it appears that the Windows install automatically chose to initialize the storage drive as MBR, even though the OS was being installed on the SSD. Once in Windows, we found we were unable to convert the disk to GPT (Option was greyed out, even when running disk management as administrator).

Then, more perplexingly, we removed all partitions from that drive with PartedMagic, but then Windows would no longer boot, even if the drive was removed again. The only way forward was to reinstall Windows again. We went through this procedure twice just to make sure we didn't fat-finger something.

We also tried taking that drive to a separate Linux machine and removing all partitions. The behavior was the same, Windows would not boot when the drive was reinstalled, and would no longer boot if it was removed again. We went through the BIOS multiple times to make sure nothing had changed. We tried bcdedit from a command prompt of a Win10 installer, it detected the existing install, but could not repair the boot record.

So we did what I guess we should have done from the start and installed Windows without the storage drive connected. Then (having removed all partitions from it again), we shut down the machine and reconnected the storage drive. Now upon boot, we could initialize the disk as GPT and proceed as normal.

I swear we didn't need to do this dance in the past. We don't do many machines with extra storage drives, but I know we had one this past fall and don't remember any of this nonsense with that build.

Did something change with the Win10 install that affected how secondary drives are treated? Shouldn't we have been able to go into disk management and initialize the disk as GPT the first time we got into Windows after the install completed? If not, I guess I have a procedure to revise.
 
I can't answer parts of your question, but my scripts:

a) Completely Clean Win10 (Re)install Using MCT to Download Win10 ISO File

b) Completely Clean Win10 (Re)install Using MCT to Create a Bootable USB Drive

include a step during installation (really meant for reinstallation, but could be used) where you jump out to the diskpart command and handle the (re)initialization yourself.

If you can identify when this would be necessary versus when it wouldn't you could use that technique, or just always use it if the installation is attended, as it takes very little time if you don't need to do a "clean all," which you wouldn't on a brand new drive nor on a drive being reused for the same client.
 
So we did what I guess we should have done from the start and installed Windows without the storage drive connected. Then (having removed all partitions from it again), we shut down the machine and reconnected the storage drive. Now upon boot, we could initialize the disk as GPT and proceed as normal.

I swear we didn't need to do this dance in the past. We don't do many machines with extra storage drives, but I know we had one this past fall and don't remember any of this nonsense with that build.

I've been doing this since I can remember. Even in the XP days I used to do this. The worst is when the secondary drive dies and then the OS won't boot anymore. Even restoring an image backup results in Windows not booting unless you imaged both drives and restored them both to the new drive(s).

I don't know why this happens, but it just does. Even if the storage drive is uninitialized when you start installing Windows and has no file system the OS still becomes dependent on the storage drive in order to boot. I always just keep the SATA cable unplugged on the secondary drive(s) when installing Windows. I figured this was a bug that got fixed a long time ago but I still do this to this day out of habit. I don't know why I'm surprised that Microsoft never fixed this. They've got bugs from Windows 95 that are still in Windows 10.
 
I've not had this problem before but I usually start with just one drive and go from there. I'm I know I've done clean installs, as in re-installs, with a second or more drive hooked up. But the symptoms @HCHTech mentioned rings a bell for some reason. Have some vague recollection reading about others having the same problem. Install with 2 drives and removing spare keeps it from booting. But never investigated it much. No ones going to pay me to do that.
 
Could "Storage Spaces" cause these problems?
There's no such thing as Storage Spaces in Windows XP. I'm afraid the issue is much deeper than that. I've never tried to replicate the problem with an OS older than XP (mostly because having multiple hard drives was extremely rare in the Windows 9x days), but it wouldn't surprise me if this is a bug from Windows 95 that never got fixed.
 
There's no such thing as Storage Spaces in Windows XP. I'm afraid the issue is much deeper than that. I've never tried to replicate the problem with an OS older than XP (mostly because having multiple hard drives was extremely rare in the Windows 9x days), but it wouldn't surprise me if this is a bug from Windows 95 that never got fixed.

The OP never said anything about "Windows XP?"

Installed Win10
Did something change with the Win10 install that affected how secondary drives are treated?

...and yes, I do know there is "There's no such thing as Storage Spaces in Windows XP."
 
Well, it seems the problem lies with the install putting the MBR on the "wrong" drive for whatever reason. Remove that drive, no MBR = no boot. It must not be 100% as I know I've done multiple drive installs before without this problem, but the solution seems clear, as others have stated - don't connect the second drive until after Windows in installed. I've modified our procedures to reflect that.
 
Last edited:
I always install Windows with only a single drive connected to prevent this from happening.
The first time I encountered it was with a Samsung laptop that had a 32MB Cache drive installed, windows put the MBR partition on the cache, I wasn't actually the one that worked on that particular machine so not 100% sure how we got around it, perhaps installing Windows on another machine then putting the drive back in the laptop to complete installation.
 
Leave the 4TB drive out. Install Windows. Externally connect the WD and clean and format it using diskpart on another machine. Install WD into your new machine. Done. Thats the way I would do it. I've always installed just the OS drive and did everything prior to adding in additional drives.
 
I somehow glossed over the presence of both drives at the time of Windows installation.

Given what I've read not only here, but in many other venues, the only 100% certain way to avoid this issue is to have only the OS drive connected at the time of clean (re)installing Windows 10.
 
Having the second drive connected during Windows install shouldn't matter if it's a brand new drive. My suspicion is that drive has been used since it was manufactured, and may have had a boot record still intact so Windows used that.

Because this was a 'new build' we're assuming the HDD was brand new, but @HCHTech didn't explicitly say that. Or if assumed new it might have been bought from a retailer and might have been a returned drive resold as new.
 
Agree with all others here, remove the secondary and install windows then wipe partitions off the secondary in windows, I usually use easeus partition master.

As an additional note ... what does that SATA/AHCI controller look like? is it the standard MS driver? if it is update it to the correct driver usually intel rapid storage or something like that. I've have secondary drives completely undetected except in bios because that SATA/AHCI controller driver is the MS driver, all while the system boots and operates normally just completely unaware that there is a SATA secondary.

Initially I thought that problem was due to a SATA port being disabled due to PCI express lanes taken up by an NVme drive but turns out it was all about that SATA/AHCI driver.
 
Having the second drive connected during Windows install shouldn't matter if it's a brand new drive.
I never use used drives and I've encountered the problem many times. The new drive hasn't even been initialized and the OS still won't boot without it. I don't get it.
 
I never use used drives and I've encountered the problem many times. The new drive hasn't even been initialized and the OS still won't boot without it. I don't get it.

And I have been on other conversations, on other forums, where tons of folks I know and trust have reported precisely the same thing. I have no reason to doubt them. That the behavior is inconsistent, and no one has been able to find "the silver bullet" to cure it when multiple drives (all new or otherwise) are connected is massively frustrating.

All of us have the, "I just don't get it," reaction. Eventually, once the root cause is determined, it will be fixed. Until then, I'd rather follow the "best practice" of having only the drive I intend as the OS drive connected for the Windows 10 install. It saves having to do additional reworking.
 
The new drive hasn't even been initialized and the OS still won't boot without it. I don't get it.
I've never experienced that, but now that I know it can happen I'll keep that in mind.

I've actually added an M.2 SSD to a new laptop without removing the HDD, booted Win10 setup, deleted partitions on the existing HDD before installing to the new SSD, then after setup creating a data partition on the HDD. First time I did this I tested by removing the HDD and the laptop still booted with SSD only. I've done this several times since, because it's easier doing all the internal hardware changes in one go (no drive access bays).

I think in future I'll take the extra precaution and disconnect the HDD and partially reassemble to install Windows before going back inside and reconnecting the HDD.
 
Do your installs and look in Disk Management, if your installer went stupid, you'll see Boot, or Crash Dump on the 2nd drive's partition.

If the 2nd drive's partitions just show Primary or Secondary you're fine.

But I'm with @sapphirescales on this one, only I'll raise it a bit... because I first encountered this on NT 4.0, I saw it again in 2000, XP, 7, 8, and I've seen it three times in 10. The only way I know to work around it is to make sure extra drives simply aren't there during initial setup.

There's also another related bug of sorts... if you have a USB attached multi-card reader or similar device, sometimes that thing will get the first drive letters instead of the main drive. Windows goes on C... so I wind up nuking units to fix that junk too.

This issue can detonate a box on feature updates too... so careful!
 
Back
Top