dotchetter

Alright. it is a bit funky partitioned... but being OEM, their scripts can differ from Microsoft's sometimes, as well as labeling their partitions. For example volume 4 would normally be identified as "System" instead of just "hidden" and there's no MSR partition as far as I can see. What was the last thing before this happened? Im confused as to why you don't have an "EFI" directory in C:\Windows\Boot\ . Is the backup in a compressed file or just drag-and-drop folders? If you have space on your external drive over, say 500gb or so, I could help you capture the C:\ drive with DISM and re-apply it after reinstalling Windows entirely. that would be automating the re-partitioning phase, and then after the disk is cleaned and windows is re-installed, we can apply the image. This being OEM - I assume you know the appropriate procedure for your computer. Some manufacturers still deliver recovery CD's and some use a partition on the drive where they keep their recovery environment which can be booted to by pressing a "F.." key upon boot most of the time. I'm uncertain of your skill level so just tell me if you need in-depth help with that if you want to.

Thank you. No, it is not the issue. If it's not too much trouble, could you also upload the output of just diskpart list vol Do you by any chance have a large external harddrive? Roughly the size of the used space on your drive (500gb minimum)?

I see. Can you upload a picture or document output of Diskpart list vol sel vol C ( or your windows volume ) detail vol

If you typed the literal path that I pasted above and it did not find it, your system is probably legacy. Anyhow; If you run the command in my first post, after doing all the previous steps... but you change it to: bcdboot X:\Windows /S S: /F bios Will you get another output? You should be getting "Boot files successfully created" Enter the UEFI settings and turn off Secure Boot, and enable legacy boot or "Both" if you have that setting. Basically, a default setting resolves these settings to legacy compatible.

It could be due to the installation environment changing the driveletters. do diskpart list vol You should see there which volume letter is assigned to the Windows volume. It should be OK, this is sort of a last resort.

Check the System log in Eventlog, sort for errors and see if you can trace it down to the application or service that is causing the problem. It might be an issue with hardware accelerated rendering since it seems to occur during video or image processing and a recent change in hardware.

No, it will not alter the system installed in that way. Extracting OEM keys from computers nowadays, especially laptops is often useless. The key is stored in the UEFI, and it can be seen from there, or at least a part of it; if it is indeed a part of the UEFI. That way, no matter if you reinstall Windows, it will find the key and auto activate if it is Windows 10. But do check first to see if it's in the UEFI. This applies to laptops sold within the last 2 years I'd say with some certainty but I won't promise anything. There's a VBS you can run to retrieve the key from the registry... but I'm not sure about the legal part behind doing so.

I've seen this before. It's been related in my cases, to reagentc not being enabled, rendering the WindowsRE unable to perform the tasks. Some windows 10 installations lack the winre.wim file in Windows\System32\Recovery for some reason. You can check the status on your system by running reagentc /info from the commandline. If it is disabled, you can try running Reagentc /enable If it ends successfully, that'd be all to make it work. I have the factory winre.wim file for you if you're lacking it and cannot enable WindowsRE..

What exact REG_SZ did you change or remove? Can you still access the registry from the commandline by reg add or reg del?

Well since it's been solved already, I might as well spill the beans... yes there are ways... good old sticky keys still works, even in Windows 10.

I see. There is probably corrupted data in that file. Try this command from the installation environment commandprompt, and then repeating my previous post: copy X:\Windows\Boot\EFI\bootmgfw.efi C:\Windows\boot\EFI\ /y

No, that will not work. Often times when Windows can't boot, it's a problem with the System / EFI partition and not the Windows partition. The System partition can be recreated, although the safest thing in my opinion would be to capture the Windows partition with DISM to a .wim file, and then cleaning the drive, repartitioning it with GPT and applying the image to a new NTFS partition.

Do you have access to a windows installation? In that environment you can open a command prompt with Shift + F10. Unplug any other drives such as USB drives or external drives first. Do the following commands diskpart sel disk 0 list vol You should now see something similar to this: In my case Volume 2 is the system partition. By default, it does not have a mountpoint. Find out which of the partitions is your system partition. In Windows 10, sometimes it isn't even labeled "System", but it's usually the one partition around 100 - 200 mb in size (windows 10 tends to be larger). It is also usually the only volume to be Fat32. Now if you know which volume is your system volume, then in DISKPART, do sel vol 2 (your volume there) assign letter s exit The system volume now has a mountpoint. Now, do bcdboot C:\Windows /S S: /F all If the command above ran successfully, it has recreated new bootfiles based upon the data in the windir. You can now try and boot the system.

My guesses are that if it is hardware related, certain sectors could've gotten rendered bad making the volume unbootable. But you said the drive is indeed fine.. so ruling that out; If you mounted the drive on another system, there are a few things you can try. Hook it up to the system again, and find out what drive letter a.k.a. Mount Point it is given. Usually it's D but it varies. Open a Command Prompt as Administrator (Windowskey + X , M) and paste the following command where you replace MOUNTPOINT with the driveletter for the bad drive. (most likely " D:\ " ) dism /online /cleanup-image /restorehealth /source:MOUNTPOINT:\ After that, you can also run this command to create new bootfiles for the installation. Again, replace MOUNTPOINT like you did above. bcdboot MOUNTPOINT:\Windows /s MOUNTPOINT: /f all This command creates new bootfiles for both efi and legacy partitions, and a case of excessive ones means no harm.

What kind of key do you have? KMS keys require a KMS server as an example. Without a present kms server that could cause similar issues. you can try running slmgr -dli in on your machine and see what you get. RETAIL is the common type of key for 1-1 machines. KMS is.. well not ideal unless you're part of an IT infrastructure.