Accidentally Made UEFI System Unbootable. What did I do wrong?

[The Dude]

Oops...I did it again (something stupid with a computer, that is)! I've been caught off guard by recent developments in the tech world. Truly appreciate some assistance here so I can learn what I did wrong.

I just built a new machine and was trying to replicate what I successfully did on my old one. Here is my old machine and what I used to do with it:
-Gigabyte motherboard (forget exact type...purchased about 2014. I don't think it had UEFI, but I have no idea).
-Drive A: Windows 7 on a SATA SSD (unencrypted).
-Dirve B: Windows 7 on a SATA mechanical HD (full disk encryption with Veracrypt).
-I would use the BIOS boot order to select the SSD for games or anything that needed speed. I used the mechanical HD for anything involving personal data.

But now I built a new machine:
-MSI Tomahawk Z370 with UEFI.
-Drive A: Windows 10 on M2 SSD (unencrypted).
-Drive B: Windows 10 on SATA mechanical HD (I tried to encrypt this with Veracrypt, but ended up tanking my whole system).

Initially, before attempting system encyption, my MSI motherboard would simply prompt me which copy of Windows I wanted to run on startup. I could easily select one or the the other and both booted fine.
But then I tried to encrypt the one and encountered some problems:
-When trying to do system encryption from Drive B, Veracrypt warned me something like, "it doesn't look like Windows is installed on the disk which it boots from." I should have stopped here and asked for help. But instead, I loaded disk management utility, verified that Drive B was a single parition, with Windows in fact installed, and then proceeded past the warning.
-"Hidden" and "encrypt the whole drive" options were greyed out. I thought this was strange, because they never used to be greyed out on my old system. I selected "normal" and "encrypt the Windows system partition."
-For "Number of Operating Systems," I don't totally recall, but I think "multi-boot" was greyed out, leading me to select "single-boot."
-I then set a password and left "Use PIM" unchecked.
-For the rescue disk, I had specifically ordered some old, stupid DVDs just to make a rescue disk for Veracrypt. I was shocked to see it asking me for a USB stick, which I didn't have! So I told it to skip rescue disk verification and just clicked through without actually creating a rescue disk. I understand this is kind of stupid, but my Drive B is currently blank with a fresh OS on it, so I figured I have no data to lose and I can go get the .iso later...

Veracrypt told me it would reboot to perform the test. Upon restart, I am prompted for password, PIM, and hash. Entering the 100% correct password, and pressing enter to leave PIM blank (or even trying 426 and 0 for shits and giggles) does not work. I cannot boot EITHER of my Windows 10 drives now!

I have successfully destroyed my entire system. Why can't I load my unencrypted drive? Selecting that drive in the MSI interface still makes it ask me for Veracrypt password!

No data have been lost, since I have everything backed up. But where did I go wrong? How can I get this right next time? I suspect this new-fangled UEFI tech is messing up my old method.

:)

[John Deener]

This is a shot in the dark but it may be the same problem I had while installing Linux to a drive. I had set up my motherboard to boot a certain drive first "HD2". It was NOT the natural first boot. The actual connection. The first "natural" connection/boot would be named on the board HD0. When Linux installed it didn't install to the drive I selected , even though it showed it as going to another drive, it installed to drive HD2 which was my windows system drive. Example.

I have drive HD0
HD1
HD2

These are the sata connection labels that I'm using for drive naming but when Linux is running the motherboard confuses it by making HD2= to HD0
I make the motherboard boot to HD2 first. Linux actaully shows it installing to that drive HD0, checked the size. but then it actually installs to HD0.

What a nightmare. That was my windows system drive took me forever to fix it.

I wonder if veracrypt is ignoring the motherboard drive sequence and instead using the actual drive. I mean on the motherbaoard in my case the HD0 sata port on the board???

Now when I install any OS I undo all my drives except the one I'm working on.

[The Dude]

Thanks, John. That's not my exact problem though.

I went ahead and decided to start clean by first reformatting the Drive B; I later planned to reformat Drive A. I installed a fresh Windows 10 copy over Drive B. During the install process, Windows 10 rebooted itself. To my pleasant surprise, I was presented with a choice: boot from Drive A or Drive B (the behavior I saw before attempting to encrypt Drive B). Drive A still works. It's a Christmas miracle!

I now have both drives working properly, both unencrypted. I'm scared to try to encrypt Drive B again, since I now realize how complicated this is and how I have no idea what I'm doing.

I hope someone can reply to this post to guide me in the right direction :)