AMD : BSOD unsupported processor since Windows build 26100.4202+ ( update kb5060842 + its preview kb5058499 )

[masato]

View attachment 87896
As expected the RTX 3090 is working properly, no issue.

Step 2: Updating to the latest KB...
View attachment 87897
Still working fine, unexpectedly

Step 3: Updating to the latest Nvidia Drivers, as stuff like rebar is not enabled with the default MS provided drivers.
View attachment 87898
And still working fine.

Step 4: install the QA-Agent and the virtio 271 stuff.


Step 5: check the windows stuff like vm in vm support

It's still the case that you can't obtain the PCI-E link speed with GPU-Z.
Do you get a BSOD when you shut down or reboot after starting GPU-Z?
The event log will show an error saying that the GPU is locked.

In previous KVMs, GPU-Z was able to display the PCI-E link speed and output a BIOS file, but this is no longer possible.

 

[butch2k]

It's still the case that you can't obtain the PCI-E link speed with GPU-Z.
Do you get a BSOD when you shut down or reboot after starting GPU-Z?
The event log will show an error saying that the GPU is locked.

In previous KVMs, GPU-Z was able to display the PCI-E link speed and output a BIOS file, but this is no longer possible.

Agreed, there is something fishy.
I can get pcielink speed when cpu type is not host but not when i'm in host mode, i'm pretty certain it used to work fine.
Moreover i set the new VM to the exact same configuration as the old one, same virtio stuff, same windows patches, same windows functionnalities enabled, same nvidia drivers (even ddu-ed the old old), but it works in host mode for some reasons.

 

[_gabriel]

so you can edit previous posts to correct wrong statement.
BSOD unsupported processor is present only with June 2025 ( kb5060842 )
Microsoft fixed it with July 2025 ( kb5062553 )

 

[butch2k]

so you can edit previous posts to correct wrong statement.
BSOD unsupported processor is present only with June 2025 ( kb5060842 )
Microsoft fixed it with July 2025 ( kb5062553 )

I won't be so fast as the problem is present with VMs which went through the whole update process (going through all KBs) but not with the ones which only got the lastest patch. I still have to investigate the root cause, going back to old VM backups and see if can reproduce while going to the latest patch, check various kernel options, versions, etc... it might be an interaction between the KB and something i missed.
For instance i mentionned earlier on that my 26200 image was unnafected as it was not updated since april, i patched it with the latest KB a couple of days ago and it is now affected similarly as my 26100 images.

 

[_gabriel]

(going through all KBs) but not with the ones which only got the lastest patch.

Updates are Fully Cumulative since Windows 10, there isn't diff between build July 2025 and a Monthly updated RTM build since October 2024.

still have to investigate the root cause

Agreed and thanks for your reports , but as new Topic to avoid confusion.

 

[butch2k]

Updates are Fully Cumulative since Windows 10, there isn't diff between build July 2025 and a Monthly updated RTM build since October 2024.

Agreed and thanks for your reports , but as new Topic to avoid confusion.

I will open a new topic.

I agree on the cumulative vs monthly upgraded, but there might be differences in registry entries created at one point or maybe some errors during montly patch install.

 

[masato]

If you recreate the EFI Disk or TPM Disk, it doesn't work.

 

[masato]

Agreed, there is something fishy.
I can get pcielink speed when cpu type is not host but not when i'm in host mode, i'm pretty certain it used to work fine.
Moreover i set the new VM to the exact same configuration as the old one, same virtio stuff, same windows patches, same windows functionnalities enabled, same nvidia drivers (even ddu-ed the old old), but it works in host mode for some reasons.

After switching to X86-64-V4, the PCI-E link speed was displayed in GPU-Z.
3DMARK, which had not worked before, also ran. However, it was slow.
The FF16 benchmark score was roughly the same.

 

[masato]

Even when the CPU type was set to QEMU64 and the CPU flags were set to the same as the HOST, both GPU-Z and 3DMARK worked properly.

GPU-Z and 3DMARK will not work if you remove the flags from EPYC.

 

[cwt]

Regarding the code 43 problem:

cpu: host,hidden=1

within the VM‘s conf has been set?

 

[butch2k]

Regarding the code 43 problem:

cpu: host,hidden=1

within the VM‘s conf has been set?

Yes in tested more than a few options, and none worked. What works is changing the cpu type to anything other than host, or a complete system reinstall. Like masato underlined there are very unusual behavior with gpuz as well, for instance pcie link speed is wrongly reported and does not match lspci stats, while it worked fine before.

 

[masato]

I think you should create a custom CPU model based on QEMU64 with the host CPU flags set.
Below is a custom model with all the Ryzen 9950X flags specified.

/etc/pve/virtual-guest/cpu-models.conf
-----
cpu-model: qemu64-ryzen9000
flags +abm;+adx;+aes;+arat;+arch-capabilities;+avx-vnni;+avx;+avx2;+avx512-bf16;+avx512bitalg;+avx512bw;+avx512cd;+avx512dq;+avx512f;+avx512ifma;+avx512vbmi;+avx512vbmi2;+avx512vl;+avx512vnni;+avx512-vp2intersect;+avx512-vpopcntdq;+bmi1;+bmi2;+clflushopt;+clwb;+clzero;+cr8legacy;+erms;+f16c;+flush-l1d;+flushbyasid;+fma;+fsgsbase;+fsrm;+fxsr_opt;+gfni;+ibpb;+ibrs;+invpcid;+kvm_pv_eoi;+kvm_pv_unhalt;+lbrv;+misalignsse;+mmxext;+movbe;+movdir64b;+movdiri;+npt;+nrip_save;+osvw;+overflow-recov;+pause-filter;+pclmulqdq;+pdpe1gb;+perfctr-core;+pfthreshold;+pku;+pni;+popcnt;+rdpid;+rdrand;+rdseed;+rdtscp;+sha-ni;+smap;+smep;+ssbd;+ssse3;+sse4.1;+sse4.2;+sse4a;+stibp;+succor;+svm;+topoext;+tsc_adjust;+tsc-deadline;+tsc-scale;+umip;+v-vmsave-vmload;+vaes;+vgif;+vmcb-clean;+vme;+vnmi;+vpclmulqdq;+wbnoinvd;+xgetbv1;+xsave;+xsavec;+xsaveerptr;+xsaveopt;+xsaves
hidden 1
reported-model qemu64
-----

 

[MisterT]

So is anyone else having this code 43 problem or am I safe to update now?

 

[masato]

In an AMD environment, code 43 does not occur.
In an Intel environment, code 43 occurred when starting up in an NVIDIA environment, but when I changed VGA to "none" and started up again, code 43 disappeared.

 

[LuixSP]

What is the “host” CPU?

Host CPU is passing the guest OS the physical CPU you have in your machine. So, theoretically, it's inheriting the actual CPU in your machine.

 

[guruevi]

@LuixSP I am aware, I was asking what the actual CPU was. AMD, especially desktop AMD are notoriously poor candidates for virtualization.

 

[MisterT]

@LuixSP I am aware, I was asking what the actual CPU was. AMD, especially desktop AMD are notoriously poor candidates for virtualization.

That's interesting because I have found the exact opposite to be true in more recent times. The 7950X3D was the ultimate VFIO CPU for nornal consumer use, and I would imagine the 9950X3D is currently.

 

[P=P]

I could not reproduce the problem using another System based on Ryzen 7 8845HS (ZEN4) with BlueStar Linux (Kernel 6.12.7) and Virt-Manager (QEMU).

But I have the problem @ryzen 9 6900HS (ZEN3+) with PROXMOX 8.4.1 (Kernel 6.8.12.9).

Also not !!! @ryzen 9 7945hx PRO with PROXMOX 8.4.1...

And NOT @Hyper-V and ESXi @ryzen non-PRO Processors.

To me, it looks like a problem with the specific combination of NON-PRO Ryzen running at older Kernels.

I did set up new VMs for the clients with WIN 11 pro/Enterprise #24H2 and freezed all updates of WIN by changing the update server's addresses inside REG32 to X instead of the addresses. And isolated the machines from the internet meanwhile, by using copies of the VMs to test new updates before I update the productive VMs manually in future.

My MS Support (SoftwareONE AG, Stans) could only help me by advising me to surpress those updates. What was really helpful.

But obviously I am not alone with this PROXMOX specific problem. Or kernel-specific problems. I am convinced that all those epic processors mentioned here have PRO Features?! Otherwise, it might be a processor-specific problem, too.

 

[_gabriel]

@P=P
Have you read previous posts ?

BSOD unsupported processor is present only with June 2025 ( kb5060842 )
Microsoft fixed it with July 2025 ( kb5062553 )

 

[P=P]

That's interesting because I have found the exact opposite to be true in more recent times. The 7950X3D was the ultimate VFIO CPU for nornal consumer use, and I would imagine the 9950X3D is currently.

Me2. I use a lot of mini PCs for VMs, most @ryzen 7 and Ryzen 9 - based Hardware and I am very, very surprised about the extreme performance of those systems. They could easily mess up with those running @Xeon-based Hardware. Even with larger ms-sql databases - they made me and the customers really happy. Even in x86-64 mode, they stay very performant. So I could not agree with it has been said that ryzens are bringing up a poor performance for virtualization.

Maybe that was right for very old processors, but for example, on a Ryzen 9 6900HS, I have really performant SQL-Surroundings running, month after month at high performance.

One should not compare benchmarks with real life performance, I think. Looking at those benchmarks, I probably would agree, but my real life experience is something completely different.