As stated in the thread title, the build:
MSI A68HI AC
Athlon x4 845
16GB (2x 8GB) DDR3 1600
R9 380 4GB
SanDisk 1TB SSD
Latest BIOS, I can install Windows 7 and Ubuntu, Verified Secure Boot settings are enabled. Reset BIOS. Windows 8.1 stalls out at 59% install, Windows 10 get stuck in a boot loop. Date/Time accurate… OC all on auto…Windows 10 will not boot.
Installed Ubuntu 20… Still looking for the answer…
IIRC, if a system was able to handle Windows 8.1, it would be shoe-in for W10 [at min.]
…Why does that board sound famili-
2 Likes
Did you get Win10 to work on it? It won’t even boot just pops the MSI screen then boot loops. Might try again with Win8 and do the upgrade assistant or something…
Yes, I’ve gotten W10 to work on it
If anything be different from yours, I’ve used an A10 chip
what are your sata setting is it set to AHCI? also try disabling secure boot. you may also have hardware issues
Yeah checked the sata settings, I’m not using an APU processor… It’s an Athlon x4 845 paired with a power color R7 240…Windows 8/10 settings are on, secure boot, etc… If I try with secure boot off it let’s me know… And will not go anywhere…the thing is I can get Ubuntu to run on it, windows 7 installs and runs… 8.1 stalls out at 59% and win 10 boot loops
can it run prime 95 for 24 hours without crashing?
it is possible it’s just a bad hardware software combination it’s not common but, i’ve heard once in a rare while you get just the right hardware or software and wierd things can happen
Try changing ram sticks to other sockets, try with one stick aswell. Then try re-installing
Ram issues and or power supply issues is kinda what it sounds like. Could also be a faulty harddisk. So, try troubleshooting your way through starting with the ram.
Perhaps there is an available bios update aswell, latest is from 2016-08-23.
If u havent checked. Here’s the link
1 Like
yeah you might have point i’ve seen fault ram do some wierd shit
1 Like
Hardware fault my ass, Microsoft/AMD dropped the ball hard here.
I have the same CPU on a GA-F2A88XN-WIFI, and I could manage to boot Windows (not the installed system, but the very ISO itself) only up to 1909. Starting from 2004 everything I got was a full system reboot as soon as the spinning wheel animation should have appeared under the windows logo (alternatively, every now and then the screen hanged there while the image slowly started to corrupt).
After banging my head blindly for 4 days, I found the culprit: mcupdate_AuthenticAMD.dll. You simply have to delete this file from boot.wim (or replace it with an older one) and that’s it.
(or well, I also found out boot to fail with a ACPI_BIOS_ERROR BSOD if I disable the SATA controllers, but that’s a very minor problem probably specific to gigabyte DSDT)
I then used MCExtractor to compare the two versions, and indeed it seems like they are shipping microcode for 660F01 (the Carrizo CPUID) since 20H1. And I’m wondering some things now.
It is allegedly something to handle Spectre (it was authored on 2018-01-26 after all), but I couldn’t find it in any linux repository. Only windows seems to ship it. Or some bioses, even though they seem to apply and note the same mystical 0600611A revision for Bristol Ridge instead (which is so different it has a totally different AGESA).
So, is there some relatively mundane bug in the microcode that QA missed, or could it be they are matching the actually damn wrong cpu to it? (it’s not even the first time they mix up the various excavator cores “subgens”)
I may have to try that, delete that file… I’m currently running win7, and doing CPU mining… Thinking about making it an emulation machine…
So? Progress?
I tried to write to amd back in december, but even after enduring every possible copypasted reply of theirs (including “it’s not in this list sorry” and “can you send dxdiag”) and explaining everything precisely they left me hanging for a reply.
And I wouldn’t know how to contact microsoft, which anyway I believe to be even more of a black hole for customer support.
hey i have a same problem. so i replace this file with a one from build 1909 and in this moment i can pass first part of instalation win10 but after restart i get stuck on windows logo…
I was trying to inject this file in last verstion of win10 (iso-boot.wim)
also this file you can found on 4 location in two different (win pe and winpe setup)
in both of this (winpe and winpe setup) you can found him in same location.
so i replace all of them with 1909 file.
i get first step instalation done but after restart i get same logo stuck and slowly start to corrupt.
ok. i found a problem. you also need to replace this file in install.wim
You could also just delete C:\Windows\System32\mcupdate_AuthenticAMD.dll.
Sigh… I run sfc /scannow because (stupid) reasons, and the next time I rebooted I got greeted by the “snowing pixels” windows logo. (and yeah, I repeated the procedure and everything was just fine then)
I got to wonder if there couldn’t have been other methods to skip the microcode update tho.
And I reckoned the answer is probably no.
It’s not even the kernel to load the thing, but winload. And even after skimming its source code (turns out osloader was included in the W10 shared source kits leak) I couldn’t really tell for any related knob to exist.
So… I was trying PatchPAE (on the same cursed PC coincidentally) when two biggies hit me.
First (at least if Windows is installed in UEFI mode) you can throw the efi shell and a ntfs driver in the boot partition. So that you’ll always have a backup plan if the gods decide it’s time for files verification to screw you.
Second (and nearing the point you could even call this an all-around solution) the “trigger” inside of winload may not have any adjustable options, but that’s not just any file.
Being the OS loader, not only has nothing is minding to it after boot, but it can even be “detoured” around with just the bat of a bcd command. The original unaltered copy can then sit in its usual place (making sfc, dism or whatever happy), while Windows gets actually loaded by something else that can actually be persuaded not to load the microcode dlls.
And this something could either be:
- a hacked copy of the original (aka winloadx.exe), say even just with the “mcupdate” strings getting one letter swapped with another
- an alternative bootloader altogether (even though I’m only aware of Quibble atm)