So, I've been currently running about 20 Windows guests (using VirtIO SCSI) in my home environment across 8 different PCs running Proxmox for several years. The Proxmox host PCs have a wide range of hardware ranging from an old Intel 4770k to a newer Ryzen 3700X. All systems using NVME ssds and sata SSDs as their primary drives.
About a week ago, I experienced major corruption on my router PC (Lenovo M715Q with multiple NICs) running proxmox and OPNSENSE as a VM. Drive corruption required me to reimage the disk from a backup I made.
This week, I decided to push the latest windows updates out to all my home PCs from WSUS server. During the May 2025 Windows cumulative update process from my WSUS server, all my home PCs and VMs succeeded successfully except for 4. These four exceptions were corrupted on three different machines. Two on an intel 4770k Based system, one AMD FX based system, and one AMD Ryzen 3700X based system. At this point the systems were not able to update, one was not able to boot. The three that were able to boot were not able to even perform an 'in-place' upgrade / repair from current Windows 11 ISO media. I began two days of OS repairs and troubleshooting as I did not have backups of these systems. I also thoroughly tested the NVMEs in all machines for any corruption, bad blocks, bad smart values, etc. Tested RAM, etc.
I also attempted forcefully installing the latest cumulative update by downloading the standalone installer, because I thought maybe something was corrupted when it was downloading from my WSUS server, even though every other system completed successfully. While performing DISM repair commands, all four corrupted systems were failing to repair, failing to clean component store, failing to "/restorehealth". Upon examining CBS.log and DISM.log on these systems, I kept noticing some strange errors that I haven't seen in 20 years of windows update fuckery.
Then inspecting DISM.log, I kept seeing mentions of 0x80007025d during update, repair, and dism repair challanges.
That stop code translates to:
HRESULT=0x8007025d (ERROR_BAD_COMPRESSION_BUFFER)
After hitting walls repairing the corrupted VM(s), I made a clonezilla image of one of the corrupted VMs, and restored it to my main desktop system running in a virtualbox VM. There I attempted an in-place upgrade/repair using windows media and it succeeded. So, that confirmed my suspicions about something happening with Proxmox or a proxmox scsi driver. At this point, I went back to two of the bootable, but corrupted Win11 guests on two different proxmox hosts, and changed VirtIO Scsi controller drivers, changed to SATA instead of Virtio-scsi, etc. I spent the next 2 days trying to track down the exact issue causing this instability. Every change I made, took about an hour or so to test on an installation of windows, so this has been extremely slow and frusterating. Seeing that "Bad Compression Buffer" made me think it was a deep seeded bug related to the SCSI controller drivers or cache settings, so one by one I tried each cache setting and attaching the drive in every combination of ways to the VM with each controller available. All attempts failed on a repair install, or manual DISM /cleanup-image /restorehealth, etc.
Finally, on two proxmox hosts, I attempted to create fresh new VMs and install Windows 11 from an ISO. Each system failed at ~98% completion with 0x8007025d. This immediately told me something was wrong with recent proxmox updates. After changing settings and trying multiple configurations, I downgraded the machine type from Q35 version 11.0 to Q35 v10.2 and all installs progressed properly. I then attempted repairs on the other corrupted VMs that kept throwing 0x8007025d stop errors after setting Q35 v10.2 and all systems successfully repaired (except for the one so badly damaged that neither a repair, nor DISM tools could repair the corruption).
That said, over the past couple years, when a new machine type version has become available, I've gone through each VM and updated it's architecture to it. This time was no exception; however, everything appeared to operate correctly, until it didn't. I never attempted a fresh install on v11.0 because I haven't had a new need until now. I have noticed a few posts on this forum with people reporting that same error on Windows VMs (0x8007025d) with no replies or comments. As I said previously, I also experienced drive corruption on my router PC running OPNSense which is based on FreeBSD, so it's not 100% limited to Windows. After 5 days of troubleshooting, I can confidently say that whatever is happening, it's happening when Machine type is Q35 and Version is 11.0.
I'm not exactly sure why 11.0 is triggering these failures based on the change log, but I do see memory and IOMMU changes, etc. This has affected mutliple VMs running multiple OS on vastly different host machine specifications.
About a week ago, I experienced major corruption on my router PC (Lenovo M715Q with multiple NICs) running proxmox and OPNSENSE as a VM. Drive corruption required me to reimage the disk from a backup I made.
This week, I decided to push the latest windows updates out to all my home PCs from WSUS server. During the May 2025 Windows cumulative update process from my WSUS server, all my home PCs and VMs succeeded successfully except for 4. These four exceptions were corrupted on three different machines. Two on an intel 4770k Based system, one AMD FX based system, and one AMD Ryzen 3700X based system. At this point the systems were not able to update, one was not able to boot. The three that were able to boot were not able to even perform an 'in-place' upgrade / repair from current Windows 11 ISO media. I began two days of OS repairs and troubleshooting as I did not have backups of these systems. I also thoroughly tested the NVMEs in all machines for any corruption, bad blocks, bad smart values, etc. Tested RAM, etc.
I also attempted forcefully installing the latest cumulative update by downloading the standalone installer, because I thought maybe something was corrupted when it was downloading from my WSUS server, even though every other system completed successfully. While performing DISM repair commands, all four corrupted systems were failing to repair, failing to clean component store, failing to "/restorehealth". Upon examining CBS.log and DISM.log on these systems, I kept noticing some strange errors that I haven't seen in 20 years of windows update fuckery.
Code:
dism /online /cleanup-image /restorehealth /source:WIM:Z:\26200.8457_amd64_en-us_multi_a90228a3_convert\ISOFOLDER\sources\install.wim:1 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.26100.5074
Image Version: 10.0.26200.8246
[========================= 44.5% ]
Error: 605
The specified buffer contains ill-formed data.Then inspecting DISM.log, I kept seeing mentions of 0x80007025d during update, repair, and dism repair challanges.
Code:
2026-05-15 05:39:24, Error DISM DISM Package Manager: PID=7332 TID=3300 Failed finalizing changes. - CDISMPackageManager::Internal_Finalize(hr:0x8007025d)That stop code translates to:
HRESULT=0x8007025d (ERROR_BAD_COMPRESSION_BUFFER)
After hitting walls repairing the corrupted VM(s), I made a clonezilla image of one of the corrupted VMs, and restored it to my main desktop system running in a virtualbox VM. There I attempted an in-place upgrade/repair using windows media and it succeeded. So, that confirmed my suspicions about something happening with Proxmox or a proxmox scsi driver. At this point, I went back to two of the bootable, but corrupted Win11 guests on two different proxmox hosts, and changed VirtIO Scsi controller drivers, changed to SATA instead of Virtio-scsi, etc. I spent the next 2 days trying to track down the exact issue causing this instability. Every change I made, took about an hour or so to test on an installation of windows, so this has been extremely slow and frusterating. Seeing that "Bad Compression Buffer" made me think it was a deep seeded bug related to the SCSI controller drivers or cache settings, so one by one I tried each cache setting and attaching the drive in every combination of ways to the VM with each controller available. All attempts failed on a repair install, or manual DISM /cleanup-image /restorehealth, etc.
Finally, on two proxmox hosts, I attempted to create fresh new VMs and install Windows 11 from an ISO. Each system failed at ~98% completion with 0x8007025d. This immediately told me something was wrong with recent proxmox updates. After changing settings and trying multiple configurations, I downgraded the machine type from Q35 version 11.0 to Q35 v10.2 and all installs progressed properly. I then attempted repairs on the other corrupted VMs that kept throwing 0x8007025d stop errors after setting Q35 v10.2 and all systems successfully repaired (except for the one so badly damaged that neither a repair, nor DISM tools could repair the corruption).
That said, over the past couple years, when a new machine type version has become available, I've gone through each VM and updated it's architecture to it. This time was no exception; however, everything appeared to operate correctly, until it didn't. I never attempted a fresh install on v11.0 because I haven't had a new need until now. I have noticed a few posts on this forum with people reporting that same error on Windows VMs (0x8007025d) with no replies or comments. As I said previously, I also experienced drive corruption on my router PC running OPNSense which is based on FreeBSD, so it's not 100% limited to Windows. After 5 days of troubleshooting, I can confidently say that whatever is happening, it's happening when Machine type is Q35 and Version is 11.0.
I'm not exactly sure why 11.0 is triggering these failures based on the change log, but I do see memory and IOMMU changes, etc. This has affected mutliple VMs running multiple OS on vastly different host machine specifications.
