Thanks for the quick reply, but I had a bad choice of words, it's booting fine, just doesn't seem like it's doing anything. I'm still getting the non-genuine prompt and I still cannot activate.
Here's a curveball that could make me look like an idiot. I don't see SLIC which probably means I don't even have SLIC in my BIOS. Am I looking at the wrong tool completely to try and activate windows? I was led here because Windows Loader said "Unsupported partition table" and the fact that I know that 3TB drives cause some issues.
Hmmm, first off, I really appreciate your help. You have some great instructions and very prompt replies, so thank you! It is GPT according to the disk management, but AIDA doesn't show anything.
The pleasure is mine! I updated my previous posts, please start from "If the disk is GPT formatted then trace the SLIC loading process..." in post #226.
Thanks for the help John. While I consider myself reasonably okay with tech, I'm completely confused with the terms/instructions probably because I have no clue what any of this really is. What I've understood is running AIDA64 as well as running the install.bat (I've tried running it with an elevated CMD as well as the admin). After that I'm lost. I'm confused as to what bcdedit /enum firmware is. This isn't a cmd command, am I supposed to use it in a bat file or? And the other thing is the debug build of BOOTX64.EFI. I can't seem to find it in the thread, and even then, I'm not quite sure what to do with a .EFI file. Thanks again for all the help, and sorry for the need for clarification, I know I'm a bit of a handful here.
nononsence, thank you for your great hard work! "Release_06-16-2012" (install.bat) with MB "MSI Z68A-G43 (G3)", CPU i5 2500, GPT HDD, works fine!
What's the resulting difference? Why would it matter how memory is written if the resulting memory content is identical?
If the problem was caused by an undocumented extension to the firmware like a change to the memory type enumeration, then it is possible that WindSLIC could request the incorrect memory type to move the ACPI tables into and be the cause of the described issue. using the ACPI table protocol in the second version would rule that out.