I'm trying to clean-install Windows 11 on a desktop that previously ran Windows 10 and Ubuntu. The target SSD is brand new and completely wiped. I've tried several USB ports, including both USB 2.0 and USB 3.0 ports connected directly to the motherboard, along with multiple USB creation tools and ISO files.
The graphical installer rejects product keys purchased from a third-party reseller as invalid. Choosing "I don't have a product key" also eventually produces a message saying Windows can't verify the product key. The installation fails even when no key is entered at all.
I also created a bootable USB containing install.wim and tried deploying it manually with DISM. DISM reports that the operation completed at 100% almost immediately, but the destination drive remains empty, so bcdboot fails afterward because there is no Windows installation to boot. The official media tool instead created split install.swm files, which has made the manual DISM process more confusing.
Adding an ei.cfg file to select Professional edition did not resolve the issue. Setup logs mention error 0x80070490, along with telemetry and EULA extraction failures during product-key validation. I'm unsure whether the USB media is corrupted, the ISO is invalid, the DISM command is wrong, or whether a BIOS/UEFI or hardware setting is interfering. What should I check next?
3 Answers
Before chasing BIOS problems, rebuild the installer from a freshly downloaded ISO on a different flash drive. A USB can still display its files while having read errors or a damaged source image. Verify the ISO checksum if one is available, write it in UEFI/GPT mode, and try a rear motherboard USB port. Also test the same drive on another computer if possible.
The key is probably a separate issue. Windows can be installed without entering one, and activation can be handled later. A cheap reseller key may simply be invalid or for the wrong edition, so don’t use it as proof that the installation media is broken.
For a manual install, make sure DISM is targeting the correct image and destination. First identify the drive letters from the recovery environment because Windows may not be C:. You can use diskpart and dir to confirm them. Then check the image indexes with something like `dism /Get-WimInfo /WimFile:D:sourcesinstall.wim`, and apply the selected index to the Windows partition with the correct `/Apply-Image` command.
If the source is split into SWM files, point DISM at the first file and include the rest with the appropriate split-image option, or use a single install.wim from a full ISO. A suspiciously instant 100% completion followed by an empty destination usually means the source path, destination path, or image file was wrong—not that deployment actually succeeded. After applying the image, format the EFI partition as FAT32 and run bcdboot using the actual Windows and EFI drive letters.
I may have been assuming the destination was C: when the recovery environment assigned different letters. I’ll verify the partitions and image indexes first instead of trusting the letters shown in normal Windows.
Reset the disk completely before retrying and boot the installer in UEFI mode. In the setup command prompt, use diskpart to select the new SSD, clean it, convert it to GPT, and let the normal installer create the EFI, MSR, recovery, and Windows partitions automatically. Be extremely careful to select the correct disk because clean erases it.
Also check that the firmware is using UEFI rather than legacy/CSM mode, and temporarily disable unusual storage-controller settings if applicable. ACPI is unlikely to be the cause of product-key validation errors; bad media, an incorrect image command, edition mismatch, or a problematic SSD/USB device are much more likely.
That was my thought too, but the installer fails even when I skip the key completely. I’m going to try a newly downloaded ISO and a different flash drive before spending more time on the deployment commands.