Installing Windows 10 20H2 with Hyper-V, Xeon CPU, and floppy disk drivers on an AMD system.
Installing Windows 10 20H2 with Hyper-V, Xeon CPU, and floppy disk drivers on an AMD system.
Performing a fresh setup of Windows 10 Pro 20H2 on an AMD system with no Intel components was straightforward. I reviewed Device Manager to identify any missing drivers, turned hidden devices on, and discovered some unusual entries. Notably, under the CPU section, there were two entries for an Intel Xeon CPU alongside my own 8-core AMD processor. I also found two floppy disk controllers listed, which is unexpected since this machine doesn’t have a traditional floppy drive controller. Hyper-V devices appeared throughout the system. After opening Programs and Features, I disabled Windows features to see what was active—Hyper-V wasn’t enabled. This raised doubts about whether the installation was proceeding correctly. I considered a possible corrupted ISO from Microsoft and decided to download a new Windows 10 Pro 2004 ISO directly. During setup, I tried installing Windows 10 Home 20H2 instead of the Pro version, thinking it might be a test. Once installed, I opened Device Manager again and confirmed the Intel CPU, two floppy controllers, and active Hyper-V. This was a completely new installation with no upgrades. Now I’m unsure how to proceed with Windows 10 20H2 on this AMD build. I’m wondering if I might have received an incorrect image from Microsoft, or if there’s another reason for the unexpected components showing up.
I performed a complete reinstall of Windows 20H2 and captured some screenshots of Device Manager. Three images highlight extra features. Remember these additional options aren’t visible in Windows 10 2004. Only the updates bundled with Windows 20H2 appear, along with the drivers included with the OS.
I don't perceive any issues here. Hidden Devices are systems already installed on the machine. Windows provides the necessary drivers and keeps them in a disabled or unloaded state to ensure proper functionality once hardware is restored. It seems like someone may have removed your system's drive at some point, reinstalled it elsewhere, and then brought it back. You might have had repairs done or built your computer previously. If that's the case, it likely explains what happened. You also referenced "Image" and "fresh install"—it appears you're referring to restoring from an image rather than a complete fresh installation.
Are you playing with words? It really seems like you're... Well, let's clarify. If you're not, this process involves clearing all partitions from the system drive, formatting it, and installing a Windows 10 ISO image. This setup is designed for corporate or educational use. Completely wiping and rebuilding = deleting every partition on the boot drive, reformatting, and installing a pre-set Windows 10 ISO that's ready to deploy. If you're unsure, just let me know.
Hello, the same issue persists with hidden devices in Device Manager. I attempted to install Windows 20H2 using the Media Creation Tool on a USB drive, then installed it on a clean empty hard drive (using DiskPart commands). Despite trying various tools and methods, these hidden devices keep appearing. Eventually, I reported the problem to Microsoft, suspecting a faulty ISO upload during the Sysprep stage. It seems the Generalize option might not have been applied properly. Interestingly, only a handful of users have observed these drivers online, but they consistently show up on every machine I tested. The situation is even more severe in Windows Sandbox, where around 20 hidden drivers appear for an Intel Xeon processor, unlike those found outside the sandbox (which uses a different Xeon model). I’m still puzzled about their origin and how they’re generated. Meanwhile, I revisited Windows 2004 to see if anyone could clarify these mysterious drivers.
Hi Vonavi, I've come across similar issues. It seems there was an error during the creation of the original 20H2 ISO. I haven't started working on the virtual machines yet. It's good to know the problems are even more severe there. I'm currently developing a new deployment for the 20H2 Image. Unfortunately, some users tend to be enough knowledgeable to cause trouble. I anticipate a lot of questions about these hidden device drivers, especially regarding potential complications in the Labs. It wouldn't be worth the effort. However, a few developers are urging me to deploy 20H2. My response so far is to wait until it's ready. I'm testing my setup with 20H2 now. I attempted to add a script that forces Windows to re-detect unassigned drivers at that stage, which clears them. But a strange glitch causes the installation to stall for 15 to 20 minutes—this is unacceptable when using PXE for image installs. As an IT professional, I'd appreciate a clear explanation of these unexpected hidden device drivers and a solution to this issue. Anyone have suggestions?