Microsoft says Windows updates released on or after April 14, 2026, for Windows 11 and supported Windows versions are intentionally blocking vulnerable psmounterex.sys kernel drivers, causing some third-party backup applications to fail when mounting or managing disk images rather than exposing systems to known driver flaws. That makes the April cumulative update less a classic “bad patch” than a collision between Windows hardening and backup software that still depends on old privileged code. The uncomfortable part for admins is that both sides of the tradeoff matter: the update protects the kernel, while the breakage hits the very tools many organizations rely on after something goes wrong.
The April Windows 11 update, identified in user reports and vendor notes as KB5083769 for Windows 11 versions 25H2 and 24H2, arrived as a normal Patch Tuesday payload. It included security work, quality fixes, and protections such as improved handling around malicious Remote Desktop connection files. Then backup jobs started misbehaving.
The affected workflows are not merely cosmetic. Reports point to failures in image mounting, browsing backup contents, restoring from images, and Volume Shadow Copy Service operations. Acronis has reportedly told customers that the failures stem from the installation of KB5083769 and has suggested uninstalling the update as a temporary workaround.
Microsoft’s response is pointedly different. The company is not framing the behavior as an accidental regression to be rolled back. Its support guidance says the updates include routine security hardening that blocks third-party drivers with known vulnerabilities, specifically vulnerable versions of the psmounterex.sys kernel driver.
That distinction matters. A bug is something Microsoft can apologize for and patch around. A blocked kernel driver is a policy decision. Once Microsoft says the driver will remain on the vulnerable driver blocklist, the burden shifts from Redmond to software vendors and IT departments that still have affected versions in production.
The driver at the center of this incident, psmounterex.sys, is associated with mounting backup images as virtual drives. In practical terms, that lets users or administrators open an image backup and browse it as though it were another disk attached to the machine. It is one of those features that feels mundane because it usually works silently.
But a kernel-mode driver is not a helper DLL. If a vulnerable signed driver can be loaded into Windows, attackers may be able to abuse it to escalate privileges, tamper with security controls, or execute code at a level where normal endpoint defenses have less room to maneuver. The driver is not just part of the backup product; it is part of the system’s trusted computing base while loaded.
That is why Microsoft’s phrasing is so significant. Windows Code Integrity enforcement is not complaining that a backup application is unfamiliar. It is blocking vulnerable versions of a driver when the Microsoft vulnerable driver blocklist is enabled. The mechanism is defensive, and the side effect is operational pain.
The vulnerable driver blocklist is part of that shift. Microsoft has said the blocklist is enabled by default on Windows 11 devices starting with the 2022 Update and is enforced in scenarios involving memory integrity, Smart App Control, S mode, and related protections. In other words, the more secure the Windows configuration, the more likely it is to reject old kernel components.
This creates a strange experience for users. A system that is less hardened may appear more compatible. A system that is better protected may be the one where a backup tool suddenly fails. That inversion is frustrating, but it is also the reality of post-ransomware Windows administration.
The old compatibility-first model assumed that signed drivers deserved a long leash. The new model assumes that a signed-but-vulnerable driver is still a liability. April’s update is a reminder that Microsoft is increasingly willing to spend compatibility capital to close that gap.
That perception is not irrational. From the admin’s desk, the timeline is brutally simple: backups worked, Windows updated, backups failed. The fact that the failure is security-driven does not help much when a restore window is closing or a client machine needs files recovered.
Still, Microsoft’s position is defensible. If the driver is vulnerable and has been publicly tracked since 2023, continued dependence on old versions is not merely a Windows servicing problem. Backup vendors own the responsibility to ship protected drivers, update detection logic, and clear customer guidance before Microsoft’s blocklist enforcement catches up with them.
This is where vendors will be judged. A good response is not “uninstall the Windows update” as a standing recommendation. A good response is a patched agent, a version matrix, a detection script, and plain guidance explaining whether existing backup sets are safe, whether new backup creation still works, and whether only mount-and-browse restore workflows are affected.
This distinction is important for troubleshooting. If image creation still succeeds but image mounting fails, the failure mode is different from a total backup collapse. Microsoft’s support note says full image backups may still succeed while image-mount operations fail, which means some organizations may still be protected but temporarily impaired during granular restore or validation work.
That is not a small problem. A backup that cannot be browsed, mounted, or restored on demand is not operationally equivalent to a backup that has been fully tested. The industry has spent years teaching admins that “backup successful” is not enough; restore verification is the real metric. If the driver block interferes with restore verification, the security improvement arrives with a real resilience cost.
The danger is overgeneralization. Not every VSS error after April 14 belongs to this driver block. Not every backup product uses the same component. But for systems logging Code Integrity blocks against psmounterex.sys, the diagnosis is no longer mysterious.
That is not elegant, but it is actionable. It gives admins a way to separate machines with a blocked vulnerable driver from machines experiencing unrelated backup issues. In managed environments, the next step is obvious: collect those events centrally, correlate them with backup agent versions, and isolate which product builds are still trying to load the blocked driver.
This is also where endpoint management vendors should be moving quickly. RMM dashboards and backup consoles should not leave customers spelunking through Event Viewer one machine at a time. If an agent depends on a blocked driver, the management plane should flag it as a compatibility and security issue.
The lesson for admins is equally blunt. Backup software inventory can no longer stop at product name and license status. Driver versions, agent versions, and Windows security feature states now belong in the same operational picture.
That is especially true because the underlying vulnerability is not theoretical. CVE-2023-43896 describes a high-severity issue involving Macrium Reflect 8.1.7544 and earlier, with the potential for privilege escalation or arbitrary code execution. The precise affected product mix in April 2026 depends on the driver versions shipped or retained by each backup vendor, but the security class is clear: Windows is refusing to trust a vulnerable signed kernel component.
The right order of operations is vendor update first, rollback only as a contained exception. Admins should check whether their backup vendor has released an updated agent or driver, deploy it to a pilot group, confirm restores, and then continue with normal Windows patching. If rollback is used, it should be documented, time-boxed, and paired with compensating controls.
The worst outcome would be a quiet drift into permanent unpatching. Backup reliability is not improved if the restore platform becomes easier to compromise. A backup product that requires disabling current Windows security protections to function is itself now part of the risk register.
Kernel drivers are supply-chain artifacts. They are signed, distributed, installed, updated, and often forgotten. Enterprises may update the main application while legacy drivers remain on disk. MSPs may inherit old agent versions across tenants. Consumer PCs may carry years of backup utilities installed for one migration and never touched again.
Attackers understand this perfectly. Bring-your-own-vulnerable-driver techniques have become a familiar way to undermine security tools, because a legitimately signed but flawed driver can sometimes do what malware alone cannot. Microsoft’s blocklist is an answer to that pattern, but it is an answer that occasionally breaks legitimate software using the same vulnerable components.
That is the hard policy choice. If Microsoft delays enforcement forever, vulnerable drivers remain available to attackers. If it enforces aggressively, customers discover that “supported” software may still contain code Windows no longer trusts. April’s backup failures are what that transition looks like in the real world.
That is good for the ecosystem but hard on edge cases. Backup, disk encryption, anticheat systems, forensic tools, device utilities, VPN clients, and endpoint security agents all tend to live close to the kernel. The more Microsoft tightens kernel trust, the more those categories need disciplined engineering and rapid servicing.
The April incident should therefore be read as a preview, not an anomaly. Driver blocklist enforcement will keep expanding as old vulnerabilities accumulate and attackers keep reusing signed drivers. The compatibility burden will fall disproportionately on software that once treated kernel components as install-and-forget plumbing.
For Windows enthusiasts, this may feel like another example of Windows Update breaking things. For IT pros, it is more specific and more strategic. The operating system is becoming a stricter gatekeeper, and every vendor that ships privileged code now has to keep pace.
Admins should also avoid assuming that a successful scheduled backup means the environment is safe. If the April update blocks image mounting but not image creation, dashboards may stay green while restore operations fail later. That is the sort of delayed failure that turns a patching incident into an outage.
There is also a communication problem. Help desks need a short script: the Windows update is blocking a vulnerable driver, not randomly deleting backups. Security teams need to understand that backup failures may be a sign of improved enforcement rather than malware or corruption. Executives need to know whether restore capability is impaired before the next incident, not during it.
The most mature shops will fold this into existing patch rings. Pilot devices should include machines with real backup agents and real restore workflows, not just clean Windows images and productivity apps. If the pilot cannot mount last night’s backup, it has not finished testing the patch.
The ideal version of this rollout would have included louder pre-enforcement messaging to backup vendors, MSP platforms, and enterprise admins. If the driver was going to remain on the blocklist after April 14, customers should have had prominent warnings before Patch Tuesday, not only after restore workflows started failing. The more predictable the security boundary, the less it feels like a trap.
Microsoft’s ecosystem problem is scale. Windows supports a vast universe of old software, and some of that software is privileged, fragile, and business-critical. The company cannot personally certify every backup tool before every cumulative update. But when the known impact area is as sensitive as backup and recovery, a generic support note is not enough.
There is a middle ground between “never block vulnerable drivers” and “surprise, your restore workflow is broken.” Microsoft should keep the block. It should also make these enforcement changes easier to discover in Windows release health dashboards, admin centers, and update management tooling.
A vendor response should answer several concrete questions. Which product versions include the vulnerable driver? Which versions replace it? Are existing backups compatible with the fixed software? Does the problem affect only image mounting, or does it also affect snapshot creation and restore media? Can customers detect the issue centrally?
Anything less forces customers to reverse-engineer their own risk. That is not acceptable for software sold as a resilience platform. Backup vendors do not get to hide behind Windows Update when their own privileged components are the reason Windows is enforcing a block.
The market should reward the companies that treat this incident as a security advisory, not a support nuisance. Fast driver updates, transparent version tables, and honest restore guidance are now part of the product. So is the ability to operate under modern Windows security defaults without asking customers to weaken the OS.
Source: HotHardware Microsoft Responds to Windows 11's April Update Breaking Third-Party Backups
Microsoft Turns a Backup Bug Into a Security Boundary
The April Windows 11 update, identified in user reports and vendor notes as KB5083769 for Windows 11 versions 25H2 and 24H2, arrived as a normal Patch Tuesday payload. It included security work, quality fixes, and protections such as improved handling around malicious Remote Desktop connection files. Then backup jobs started misbehaving.The affected workflows are not merely cosmetic. Reports point to failures in image mounting, browsing backup contents, restoring from images, and Volume Shadow Copy Service operations. Acronis has reportedly told customers that the failures stem from the installation of KB5083769 and has suggested uninstalling the update as a temporary workaround.
Microsoft’s response is pointedly different. The company is not framing the behavior as an accidental regression to be rolled back. Its support guidance says the updates include routine security hardening that blocks third-party drivers with known vulnerabilities, specifically vulnerable versions of the psmounterex.sys kernel driver.
That distinction matters. A bug is something Microsoft can apologize for and patch around. A blocked kernel driver is a policy decision. Once Microsoft says the driver will remain on the vulnerable driver blocklist, the burden shifts from Redmond to software vendors and IT departments that still have affected versions in production.
The Kernel Driver Is the Real Blast Radius
Backup software often looks boring until it touches the parts of Windows that ordinary applications are not allowed to touch. Disk imaging, image mounting, low-level restore operations, and snapshot coordination live near the boundary between user convenience and kernel privilege. That is exactly why backup tools are useful, and exactly why their drivers become attractive targets.The driver at the center of this incident, psmounterex.sys, is associated with mounting backup images as virtual drives. In practical terms, that lets users or administrators open an image backup and browse it as though it were another disk attached to the machine. It is one of those features that feels mundane because it usually works silently.
But a kernel-mode driver is not a helper DLL. If a vulnerable signed driver can be loaded into Windows, attackers may be able to abuse it to escalate privileges, tamper with security controls, or execute code at a level where normal endpoint defenses have less room to maneuver. The driver is not just part of the backup product; it is part of the system’s trusted computing base while loaded.
That is why Microsoft’s phrasing is so significant. Windows Code Integrity enforcement is not complaining that a backup application is unfamiliar. It is blocking vulnerable versions of a driver when the Microsoft vulnerable driver blocklist is enabled. The mechanism is defensive, and the side effect is operational pain.
The Patch Tuesday Contract Is Getting Stricter
For years, Windows admins have lived by an implicit bargain: security updates may be annoying, but they generally preserve application compatibility unless there is no alternative. That bargain is fraying because the attack surface has moved downward. Modern Windows security is increasingly about refusing to load code that older Windows would have tolerated.The vulnerable driver blocklist is part of that shift. Microsoft has said the blocklist is enabled by default on Windows 11 devices starting with the 2022 Update and is enforced in scenarios involving memory integrity, Smart App Control, S mode, and related protections. In other words, the more secure the Windows configuration, the more likely it is to reject old kernel components.
This creates a strange experience for users. A system that is less hardened may appear more compatible. A system that is better protected may be the one where a backup tool suddenly fails. That inversion is frustrating, but it is also the reality of post-ransomware Windows administration.
The old compatibility-first model assumed that signed drivers deserved a long leash. The new model assumes that a signed-but-vulnerable driver is still a liability. April’s update is a reminder that Microsoft is increasingly willing to spend compatibility capital to close that gap.
Backup Vendors Are Now Part of the Patch Chain
The messy part is that end users do not buy a “kernel driver.” They buy Acronis, NinjaOne Backup, Macrium Reflect, UrBackup, or another backup product and expect restore operations to work when needed. When an update blocks a shared or inherited driver dependency, the failure appears to belong to Windows, even if the vulnerability belongs to the software stack around it.That perception is not irrational. From the admin’s desk, the timeline is brutally simple: backups worked, Windows updated, backups failed. The fact that the failure is security-driven does not help much when a restore window is closing or a client machine needs files recovered.
Still, Microsoft’s position is defensible. If the driver is vulnerable and has been publicly tracked since 2023, continued dependence on old versions is not merely a Windows servicing problem. Backup vendors own the responsibility to ship protected drivers, update detection logic, and clear customer guidance before Microsoft’s blocklist enforcement catches up with them.
This is where vendors will be judged. A good response is not “uninstall the Windows update” as a standing recommendation. A good response is a patched agent, a version matrix, a detection script, and plain guidance explaining whether existing backup sets are safe, whether new backup creation still works, and whether only mount-and-browse restore workflows are affected.
The VSS Confusion Makes the Incident Look Wider Than It Is
One reason the story spread quickly is the appearance of Volume Shadow Copy Service errors. VSS is the plumbing behind many Windows backup operations, and when it times out or returns a bad state, administrators naturally assume the snapshot layer itself is broken. That may be true in some observed workflows, but Microsoft’s note narrows the core issue to vulnerable driver blocking.This distinction is important for troubleshooting. If image creation still succeeds but image mounting fails, the failure mode is different from a total backup collapse. Microsoft’s support note says full image backups may still succeed while image-mount operations fail, which means some organizations may still be protected but temporarily impaired during granular restore or validation work.
That is not a small problem. A backup that cannot be browsed, mounted, or restored on demand is not operationally equivalent to a backup that has been fully tested. The industry has spent years teaching admins that “backup successful” is not enough; restore verification is the real metric. If the driver block interferes with restore verification, the security improvement arrives with a real resilience cost.
The danger is overgeneralization. Not every VSS error after April 14 belongs to this driver block. Not every backup product uses the same component. But for systems logging Code Integrity blocks against psmounterex.sys, the diagnosis is no longer mysterious.
Event Viewer Becomes the Arbiter
Microsoft’s recommended check is old-school Windows administration: open Event Viewer and inspect the Code Integrity Operational log. Affected systems may show Event ID 3077, indicating that a driver was blocked in enforcement mode. The entry should identify psmounterex.sys and include the relevant policy information.That is not elegant, but it is actionable. It gives admins a way to separate machines with a blocked vulnerable driver from machines experiencing unrelated backup issues. In managed environments, the next step is obvious: collect those events centrally, correlate them with backup agent versions, and isolate which product builds are still trying to load the blocked driver.
This is also where endpoint management vendors should be moving quickly. RMM dashboards and backup consoles should not leave customers spelunking through Event Viewer one machine at a time. If an agent depends on a blocked driver, the management plane should flag it as a compatibility and security issue.
The lesson for admins is equally blunt. Backup software inventory can no longer stop at product name and license status. Driver versions, agent versions, and Windows security feature states now belong in the same operational picture.
Uninstalling the Update Is the Tempting Wrong Answer
Acronis and other vendors may offer uninstalling KB5083769 as a temporary workaround, and in a narrow emergency that may be understandable. If a business-critical restore cannot wait, removing the update long enough to recover data might be the least bad option. But as general guidance, rolling back a security update to keep a vulnerable kernel driver loading is a dangerous bargain.That is especially true because the underlying vulnerability is not theoretical. CVE-2023-43896 describes a high-severity issue involving Macrium Reflect 8.1.7544 and earlier, with the potential for privilege escalation or arbitrary code execution. The precise affected product mix in April 2026 depends on the driver versions shipped or retained by each backup vendor, but the security class is clear: Windows is refusing to trust a vulnerable signed kernel component.
The right order of operations is vendor update first, rollback only as a contained exception. Admins should check whether their backup vendor has released an updated agent or driver, deploy it to a pilot group, confirm restores, and then continue with normal Windows patching. If rollback is used, it should be documented, time-boxed, and paired with compensating controls.
The worst outcome would be a quiet drift into permanent unpatching. Backup reliability is not improved if the restore platform becomes easier to compromise. A backup product that requires disabling current Windows security protections to function is itself now part of the risk register.
This Is a Supply-Chain Story Wearing a Patch Tuesday Hat
The conventional reading of this incident is simple: Microsoft shipped an update, third-party backups broke. The more accurate reading is that Microsoft changed enforcement against a known vulnerable driver, revealing stale dependencies inside backup ecosystems. That is a supply-chain problem, not merely a Windows update problem.Kernel drivers are supply-chain artifacts. They are signed, distributed, installed, updated, and often forgotten. Enterprises may update the main application while legacy drivers remain on disk. MSPs may inherit old agent versions across tenants. Consumer PCs may carry years of backup utilities installed for one migration and never touched again.
Attackers understand this perfectly. Bring-your-own-vulnerable-driver techniques have become a familiar way to undermine security tools, because a legitimately signed but flawed driver can sometimes do what malware alone cannot. Microsoft’s blocklist is an answer to that pattern, but it is an answer that occasionally breaks legitimate software using the same vulnerable components.
That is the hard policy choice. If Microsoft delays enforcement forever, vulnerable drivers remain available to attackers. If it enforces aggressively, customers discover that “supported” software may still contain code Windows no longer trusts. April’s backup failures are what that transition looks like in the real world.
Windows 11 Security Is Becoming Less Negotiable
Windows 11 has always been more opinionated than Windows 10 about hardware roots of trust, virtualization-based security, and code integrity. Those choices were controversial at launch because they raised requirements and complicated upgrades. Five years later, the practical consequence is clearer: Microsoft wants Windows clients to reject entire classes of risky low-level behavior by default.That is good for the ecosystem but hard on edge cases. Backup, disk encryption, anticheat systems, forensic tools, device utilities, VPN clients, and endpoint security agents all tend to live close to the kernel. The more Microsoft tightens kernel trust, the more those categories need disciplined engineering and rapid servicing.
The April incident should therefore be read as a preview, not an anomaly. Driver blocklist enforcement will keep expanding as old vulnerabilities accumulate and attackers keep reusing signed drivers. The compatibility burden will fall disproportionately on software that once treated kernel components as install-and-forget plumbing.
For Windows enthusiasts, this may feel like another example of Windows Update breaking things. For IT pros, it is more specific and more strategic. The operating system is becoming a stricter gatekeeper, and every vendor that ships privileged code now has to keep pace.
The Restore Button Now Needs a Security Review
The operational response should begin with a test, not a debate. Organizations using affected backup products should verify whether current backup jobs complete, whether image mounting works, whether file-level restore works, and whether bare-metal recovery paths remain viable. The answer may differ across products and versions.Admins should also avoid assuming that a successful scheduled backup means the environment is safe. If the April update blocks image mounting but not image creation, dashboards may stay green while restore operations fail later. That is the sort of delayed failure that turns a patching incident into an outage.
There is also a communication problem. Help desks need a short script: the Windows update is blocking a vulnerable driver, not randomly deleting backups. Security teams need to understand that backup failures may be a sign of improved enforcement rather than malware or corruption. Executives need to know whether restore capability is impaired before the next incident, not during it.
The most mature shops will fold this into existing patch rings. Pilot devices should include machines with real backup agents and real restore workflows, not just clean Windows images and productivity apps. If the pilot cannot mount last night’s backup, it has not finished testing the patch.
Microsoft Could Still Do Better
Defending Microsoft’s security rationale does not mean giving Microsoft a free pass. The company knows that blocking kernel drivers can break software. Its own documentation says such blocks can cause devices or applications to malfunction and, in rare cases, blue screens. That knowledge creates a higher obligation to communicate early and clearly.The ideal version of this rollout would have included louder pre-enforcement messaging to backup vendors, MSP platforms, and enterprise admins. If the driver was going to remain on the blocklist after April 14, customers should have had prominent warnings before Patch Tuesday, not only after restore workflows started failing. The more predictable the security boundary, the less it feels like a trap.
Microsoft’s ecosystem problem is scale. Windows supports a vast universe of old software, and some of that software is privileged, fragile, and business-critical. The company cannot personally certify every backup tool before every cumulative update. But when the known impact area is as sensitive as backup and recovery, a generic support note is not enough.
There is a middle ground between “never block vulnerable drivers” and “surprise, your restore workflow is broken.” Microsoft should keep the block. It should also make these enforcement changes easier to discover in Windows release health dashboards, admin centers, and update management tooling.
Vendors Must Stop Treating Drivers as Fossils
The sharper criticism belongs with any vendor that allowed vulnerable driver dependencies to linger into 2026. Backup companies sell trust. Their product is the thing customers reach for when ransomware, hardware failure, user error, or a bad update has already ruined the day. That trust cannot coexist with stale kernel code.A vendor response should answer several concrete questions. Which product versions include the vulnerable driver? Which versions replace it? Are existing backups compatible with the fixed software? Does the problem affect only image mounting, or does it also affect snapshot creation and restore media? Can customers detect the issue centrally?
Anything less forces customers to reverse-engineer their own risk. That is not acceptable for software sold as a resilience platform. Backup vendors do not get to hide behind Windows Update when their own privileged components are the reason Windows is enforcing a block.
The market should reward the companies that treat this incident as a security advisory, not a support nuisance. Fast driver updates, transparent version tables, and honest restore guidance are now part of the product. So is the ability to operate under modern Windows security defaults without asking customers to weaken the OS.
The April Patch Draws a Line Through Backup Assumptions
The practical lesson is not complicated, but it is easy to ignore because backups are often treated as background noise until disaster strikes. April’s update shows that backup health now depends on Windows security policy, driver reputation, and vendor patch velocity as much as storage capacity and job scheduling.- Organizations should check the Code Integrity Operational log for Event ID 3077 on systems where backup image mounting or restore browsing fails after the April 14, 2026 updates.
- Backup software should be updated before uninstalling KB5083769 or any related April security update, except in tightly controlled emergency restore scenarios.
- A green backup job should not be considered sufficient proof of resilience unless image mounting, file-level restore, and recovery media workflows have also been tested.
- MSPs and enterprises should inventory backup agent versions and driver dependencies across fleets rather than assuming all tenants or endpoints are affected equally.
- Vendors that rely on kernel drivers need to publish clear compatibility guidance and patched builds quickly, because Windows will continue blocking vulnerable drivers rather than preserving legacy behavior indefinitely.
Source: HotHardware Microsoft Responds to Windows 11's April Update Breaking Third-Party Backups
