Microsoft’s April 14, 2026 Windows 11 security update KB5083769, and the later optional preview update KB5083631, can stop some third-party backup tools from mounting disk images because Windows is now blocking vulnerable versions of the Macrium-associated
The headline version is simple enough: Windows is refusing to load
This matters because image mounting is not a decorative feature. For home users, it is how they recover one missing folder without rolling back an entire machine. For administrators, it is how they verify backup contents, extract individual files, and perform quick triage during a recovery incident. If that path fails with a VSS timeout or
Microsoft’s support language frames the change as intentional hardening. Windows updates released on or after April 14, 2026 add known vulnerable kernel drivers to the Microsoft vulnerable driver blocklist, and backup applications that rely on blocked drivers may fail when mounting or managing disk images. The specific driver named in the new support article is
That distinction is important. This is not Microsoft discovering that Volume Shadow Copy Service is suddenly unreliable. VSS appears in the error path because backup software often stacks several moving pieces together: snapshot creation, image handling, virtual disk mounting, driver loading, and user-interface workflows. When the kernel driver is blocked, the higher-level application may report the failure through whatever layer first notices that the expected operation did not complete.
That class of attack is especially frustrating because traditional driver signing is not enough to stop it. The driver can be real, signed, and distributed by a legitimate vendor, yet still contain a flaw serious enough to become an attacker’s route into the kernel. Once a vulnerable driver is known and weaponizable, allowing it to load indefinitely becomes a systemic risk.
But Windows servicing rarely deals in paper. Machines sit untouched. Rescue workflows are documented around older installers. Technicians keep known-good utilities on USB sticks. Small businesses renew backup habits less often than they renew endpoint agents. The result is that a driver vulnerability from 2023 can still become a visible Windows compatibility problem in 2026.
Microsoft’s blocklist is doing what it is designed to do: convert a latent security exposure into an operational failure. That is uncomfortable, but it is not irrational. A vulnerable kernel driver is not merely an application component with a bug; it is code that runs in one of the most privileged places in the operating system. If Windows has to choose between letting an old mounting driver load and preserving kernel integrity, the modern Windows security model is increasingly built to choose the kernel.
There are several plausible explanations, and not all of them require Microsoft or Macrium to have made a fresh mistake. Some affected systems may still have old driver binaries present even after application updates. Some may be running older Reflect builds because the machine is no longer actively maintained, because a perpetual license was left in place, or because a rescue environment restored an older stack. Some may be using third-party backup products or management layers that incorporated, installed, or depended on the same vulnerable driver lineage.
Driver block rules can also be more complicated than a simple product-version check. A blocklist may target a file hash, signer attributes, certificate conditions, version metadata, or a broader identity pattern depending on how Microsoft assesses the risk. If a vendor patched a driver but left confusing file metadata, reused versioning, or shipped multiple branches with overlapping components, the practical result can be hard for users to diagnose from the outside.
That is why the Event Viewer clue matters. Microsoft points affected users toward Event ID 3077 in the Code Integrity Operational log, with a policy identifier associated with the vulnerable driver blocklist enforcement. That is the difference between guessing that “Macrium is broken” and proving that Windows blocked
For IT departments, that proof is everything. Without it, help desks will chase VSS repairs, reinstall backup clients, reset services, and blame storage. With it, the incident becomes a targeted remediation exercise: identify the driver version, update the backup application, verify that the current driver is loaded, and test image mounting again.
But in this case, the more important event may be lower down. If Code Integrity blocks
This is a recurring Windows problem. Security enforcement often happens at one layer, while error reporting happens at another. The kernel says “blocked driver.” The application says “snapshot timed out.” The admin reads “VSS problem.” Every layer is telling a partial truth, and none of them alone tells the story a human needs.
Microsoft could do better here. A backup application whose driver is blocked by Code Integrity should not leave users spelunking through Event Viewer to understand what happened. Windows has invested heavily in consumer-facing security surfaces, from Windows Security dashboards to Smart App Control messaging. A blocked kernel driver that disrupts backup restore workflows deserves a clearer notification path than a cryptic event log and a misleading VSS timeout.
Backup vendors also have work to do. If an application depends on a kernel driver, it should detect when that driver fails to load and report that condition explicitly. The message users need is not “VSS timed out.” It is “Windows blocked the image-mounting driver because it is on the vulnerable driver blocklist; update the backup application or driver package.” That sentence may be unpleasant, but it is actionable.
That era is ending. The blocklist is now part of the routine servicing story, and the April 2026 updates show what that means in practice. A cumulative update does not merely patch Microsoft code; it can change which third-party kernel components Windows will tolerate. That is a powerful lever, and Microsoft is increasingly willing to pull it.
The logic is defensible. Attackers have learned that vulnerable signed drivers are a useful way to reach the kernel without writing a malicious driver from scratch. Security products can be disabled, tamper protections bypassed, and protected processes attacked once kernel execution is in play. Leaving known vulnerable drivers loadable because someone might still use an old utility is a compatibility policy, not a security policy.
Still, the enterprise impact is real. Backup software is not a game overlay or an RGB controller. It sits in the disaster-recovery path. If an update breaks the ability to mount images, that affects restore testing, audit confidence, ransomware recovery planning, and the basic promise that yesterday’s backup can become today’s rescue.
The uncomfortable truth is that Microsoft is pushing the Windows ecosystem toward a stricter model faster than some operational habits can follow. That is not necessarily wrong. It does mean that every driver-bearing utility now has to be treated like privileged infrastructure, not like an ordinary app that can be updated whenever someone remembers.
That makes backup software a natural pressure point for modern Windows security. The kernel does not know that a user likes Macrium Reflect or that a technician trusts a particular imaging workflow. It sees code requesting privileged execution. If that code matches a known vulnerable driver rule, the trust conversation is over.
This is where some users will accuse Microsoft of being heavy-handed, and there is a fair emotional case for that complaint. A person trying to recover a file from a backup does not feel safer when Windows blocks the tool they need. They feel trapped between an update they did not fully understand and a restore workflow that no longer behaves.
But the alternative is worse. If Microsoft maintains compatibility with old vulnerable kernel drivers indefinitely, attackers get the benefit too. They do not need to persuade victims to run Macrium Reflect. They need only bring a vulnerable signed driver along for the ride, if the system will still load it. The same machinery that lets a backup utility mount an image can, when flawed, become a path to system compromise.
That is why “just let me override it” is not a satisfying answer at scale. A consumer power user may be willing to accept the risk for a one-off restore. A managed fleet cannot build its security posture around thousands of one-off exceptions to kernel driver enforcement. Once a driver is known to be dangerous, the burden should shift to the vendor and the administrator to deploy a safe version, not to the OS to keep trusting the unsafe one.
The BitLocker issue is especially relevant because it shows the same broader pattern: Microsoft is tightening security assumptions around boot and trust, and edge-case configurations are feeling the squeeze. Devices with particular BitLocker PCR policy settings and Secure Boot certificate conditions may be asked for a recovery key after the update. Microsoft’s guidance frames that as a limited scenario, but for the unlucky administrator, “limited” still means a ticket queue.
The Remote Desktop warning issue is a different species of problem, more interface than enforcement. Microsoft changed how
Put together, April’s update cycle looks like a preview of where Windows servicing is headed. Updates are no longer just collections of bug fixes and CVE patches. They are policy delivery vehicles. They change trust decisions, harden old pathways, and make previously tolerated configurations visible by breaking them.
For enthusiasts, that means reading Patch Tuesday notes with more skepticism and more attention. For enterprises, it means rings, pilots, rollback planning, and restore testing are not bureaucratic rituals. They are the only way to discover whether a security hardening change has just intersected with a critical operational dependency.
The better path is to update the affected backup software and confirm that the vulnerable driver is no longer present or no longer being loaded. In the Macrium case, that means ensuring Reflect is on a version with the patched
Administrators should treat Event ID 3077 in the Code Integrity Operational log as the starting point. If the event names
There is also a subtle but crucial distinction between backup creation and image mounting. Microsoft notes that full image backup creation may still succeed while image-mount operations fail. That split can lull users into a dangerous confidence: scheduled backups may report success, while the ability to browse or restore from those images through the usual interface is broken.
That is why backup verification has to include restore-path testing, not just “job completed” status. A backup that cannot be mounted during an incident is not necessarily useless, but it is less useful than the dashboard suggests. The April update is a reminder that recovery is a workflow, not a file.
Macrium appears to have patched CVE-2023-43896 in 2023, which is exactly what vendors should do. But patching is only one part of the story. The harder question is whether every supported upgrade path reliably removes or supersedes the vulnerable component, whether the product can detect a blocked driver condition, and whether customers on old builds receive unavoidable warnings before Windows enforcement turns the issue into a restore failure.
The same standard should apply to every backup vendor. Acronis, NinjaOne, UrBackup, and others have been mentioned in user reports around the April update cycle, though the Microsoft support note specifically names
There is a business-model lesson here too. Perpetual licenses and frozen utility versions are attractive to users, but kernel-adjacent software is a poor place for permanent stasis. A PDF reader can be old and annoying. A kernel driver that is old and vulnerable is a platform risk. Vendors that sell system-level utilities need update channels and support expectations that match that reality.
For WindowsForum readers who maintain family PCs, home labs, or small-business fleets, this is the practical shift: treat backup software like firmware or endpoint security, not like a one-time utility purchase. If it installs a driver, it belongs in the patch calendar.
That balancing act is exactly why communication matters. If a vulnerable driver block is likely to affect backup software, administrators need advance notice, clear detection scripts, and precise remediation guidance. A support article after the fact is useful, but it should not be the first moment the issue becomes visible to the people responsible for recovery systems.
The Windows release health dashboard has improved over the years, but driver blocklist changes remain an awkward fit for standard KB notes. They are security changes, compatibility changes, and operational changes all at once. The average user will not read them. The average administrator may read them only after a pilot machine fails.
Microsoft could reduce the damage with better preflight tooling. Imagine Windows Update for Business reporting that a device has a driver scheduled to be blocked by the next cumulative update. Imagine Intune surfacing “vulnerable driver dependency detected” as a readiness signal. Imagine Event Viewer being supplemented by a Windows Security notification that names the blocked driver, the affected application, and the vendor update path.
None of that weakens security. It makes security enforceable without turning restore testing into archaeology. The problem with the April backup failures is not that Microsoft blocked a vulnerable driver. It is that too many users will discover the block only after the restore workflow starts failing.
For decades, Windows tolerated an enormous range of third-party kernel code in the name of compatibility. That tolerance helped build a rich ecosystem of backup tools, disk utilities, hardware monitors, fan controllers, anti-cheat systems, VPN clients, encryption products, and security agents. It also created a sprawling attack surface where old signed drivers could linger long after their flaws were known.
The modern Windows security model is less sentimental. Memory Integrity, Smart App Control, vulnerable driver blocking, attack surface reduction rules, and App Control policies all point in the same direction. Trust is becoming more conditional, more revocable, and more centrally enforced.
That will create friction. Some beloved tools will need rewrites. Some old utilities will become unusable. Some vendors will discover that “signed” is not the same thing as “safe.” Users who have built disaster-recovery habits around aging software will have to modernize those habits before the next incident modernizes them by force.
Still, the direction is right. Kernel integrity is not an optional luxury in a world where ransomware crews, credential thieves, and commodity malware increasingly look for ways to disable defenses from below the operating system’s normal guardrails. If Windows cannot say no to known vulnerable drivers, every other security promise gets weaker.
Most organizations already know this in theory. Few practice it rigorously on endpoints, especially where backup tools are decentralized or managed by MSPs. April’s driver block gives that theory a very specific shape.
Windows is becoming less willing to carry old privileged code for the sake of convenience, and that change will keep surprising anyone who treats drivers as invisible plumbing. The right response is not to romanticize the old looseness or curse every hardening change that breaks a workflow. It is to build backup practices, vendor update habits, and deployment rings around the reality that security policy now reaches all the way into the restore button — and the next blocklist update will not wait for a disaster-recovery window to make that clear.
Source: Neowin Microsoft: Windows 11 KB5083769, KB5083631 block backup apps like Macrium, here's why
psmounterex.sys kernel driver. That is not a random backup bug so much as a collision between two things Windows users both say they want: restore software that reaches deep into the system, and an operating system that no longer lets old signed kernel drivers become an attacker’s skeleton key. The awkward part is that the failure lands exactly where trust matters most — the moment someone tries to inspect, browse, or restore an image. Microsoft has made the safer choice, but it has also exposed how brittle the Windows backup ecosystem remains when security policy changes arrive through ordinary cumulative updates.
Microsoft Turns a Backup Driver Into a Security Boundary
The headline version is simple enough: Windows is refusing to load psmounterex.sys when the Microsoft vulnerable driver blocklist is enabled. That driver is used by Macrium Reflect to mount backup images as virtual drives, the feature that lets users browse an image in File Explorer rather than perform a full restore. Once Code Integrity says no, the application above it can look broken even if the backup file itself is perfectly healthy.This matters because image mounting is not a decorative feature. For home users, it is how they recover one missing folder without rolling back an entire machine. For administrators, it is how they verify backup contents, extract individual files, and perform quick triage during a recovery incident. If that path fails with a VSS timeout or
VSS_E_BAD_STATE, the user experience reads as “backup failed,” even when the underlying security event is “driver blocked.”Microsoft’s support language frames the change as intentional hardening. Windows updates released on or after April 14, 2026 add known vulnerable kernel drivers to the Microsoft vulnerable driver blocklist, and backup applications that rely on blocked drivers may fail when mounting or managing disk images. The specific driver named in the new support article is
psmounterex.sys, and the enforcement path is Windows Code Integrity.That distinction is important. This is not Microsoft discovering that Volume Shadow Copy Service is suddenly unreliable. VSS appears in the error path because backup software often stacks several moving pieces together: snapshot creation, image handling, virtual disk mounting, driver loading, and user-interface workflows. When the kernel driver is blocked, the higher-level application may report the failure through whatever layer first notices that the expected operation did not complete.
The Old Driver Problem Finally Reaches the Restore Button
The security logic is not new. Microsoft has been trying to close the “bring your own vulnerable driver” loophole for years, and the vulnerable driver blocklist is a central part of that project. The threat model is straightforward: an attacker with sufficient privilege loads a legitimately signed but vulnerable driver, then abuses that driver to gain kernel-level access, disable defenses, tamper with memory, or punch through the Windows security model.That class of attack is especially frustrating because traditional driver signing is not enough to stop it. The driver can be real, signed, and distributed by a legitimate vendor, yet still contain a flaw serious enough to become an attacker’s route into the kernel. Once a vulnerable driver is known and weaponizable, allowing it to load indefinitely becomes a systemic risk.
psmounterex.sys fits that pattern because Macrium Reflect versions 8.1.7544 and below were associated with CVE-2023-43896, a buffer overflow vulnerability that could allow privilege escalation or arbitrary code execution. The vulnerability was disclosed in 2023, and Macrium’s own release notes at the time indicated that later Reflect builds patched the affected image-mounting driver. On paper, then, the ecosystem had years to move past the vulnerable versions.But Windows servicing rarely deals in paper. Machines sit untouched. Rescue workflows are documented around older installers. Technicians keep known-good utilities on USB sticks. Small businesses renew backup habits less often than they renew endpoint agents. The result is that a driver vulnerability from 2023 can still become a visible Windows compatibility problem in 2026.
Microsoft’s blocklist is doing what it is designed to do: convert a latent security exposure into an operational failure. That is uncomfortable, but it is not irrational. A vulnerable kernel driver is not merely an application component with a bug; it is code that runs in one of the most privileged places in the operating system. If Windows has to choose between letting an old mounting driver load and preserving kernel integrity, the modern Windows security model is increasingly built to choose the kernel.
The Macrium Detail Makes the Story Messier, Not Smaller
The most interesting wrinkle is that Macrium appears to have addressed CVE-2023-43896 back in October 2023, with patched versions such as 8.1.7675 and 8.0.7690 called out in release notes. That raises the obvious question users are already asking: if the vulnerability was patched years ago, why are Macrium users seeing failures now?There are several plausible explanations, and not all of them require Microsoft or Macrium to have made a fresh mistake. Some affected systems may still have old driver binaries present even after application updates. Some may be running older Reflect builds because the machine is no longer actively maintained, because a perpetual license was left in place, or because a rescue environment restored an older stack. Some may be using third-party backup products or management layers that incorporated, installed, or depended on the same vulnerable driver lineage.
Driver block rules can also be more complicated than a simple product-version check. A blocklist may target a file hash, signer attributes, certificate conditions, version metadata, or a broader identity pattern depending on how Microsoft assesses the risk. If a vendor patched a driver but left confusing file metadata, reused versioning, or shipped multiple branches with overlapping components, the practical result can be hard for users to diagnose from the outside.
That is why the Event Viewer clue matters. Microsoft points affected users toward Event ID 3077 in the Code Integrity Operational log, with a policy identifier associated with the vulnerable driver blocklist enforcement. That is the difference between guessing that “Macrium is broken” and proving that Windows blocked
psmounterex.sys from loading.For IT departments, that proof is everything. Without it, help desks will chase VSS repairs, reinstall backup clients, reset services, and blame storage. With it, the incident becomes a targeted remediation exercise: identify the driver version, update the backup application, verify that the current driver is loaded, and test image mounting again.
The Error Message Blames VSS Because the Stack Is Too Entangled
The user-facing symptom is almost perversely misleading. Microsoft says affected apps may display errors such as “The backup has failed because Microsoft VSS has timed out during the snapshot creation” orVSS_E_BAD_STATE. Those messages point administrators toward snapshot plumbing, writers, services, and state machines — all familiar territory for anyone who has debugged Windows backup failures.But in this case, the more important event may be lower down. If Code Integrity blocks
psmounterex.sys, the mount operation cannot proceed as designed. The backup application may still bubble up a VSS-flavored error because that is the framework it uses to coordinate backup and restore tasks. The result is not just a technical failure but a diagnostic trap.This is a recurring Windows problem. Security enforcement often happens at one layer, while error reporting happens at another. The kernel says “blocked driver.” The application says “snapshot timed out.” The admin reads “VSS problem.” Every layer is telling a partial truth, and none of them alone tells the story a human needs.
Microsoft could do better here. A backup application whose driver is blocked by Code Integrity should not leave users spelunking through Event Viewer to understand what happened. Windows has invested heavily in consumer-facing security surfaces, from Windows Security dashboards to Smart App Control messaging. A blocked kernel driver that disrupts backup restore workflows deserves a clearer notification path than a cryptic event log and a misleading VSS timeout.
Backup vendors also have work to do. If an application depends on a kernel driver, it should detect when that driver fails to load and report that condition explicitly. The message users need is not “VSS timed out.” It is “Windows blocked the image-mounting driver because it is on the vulnerable driver blocklist; update the backup application or driver package.” That sentence may be unpleasant, but it is actionable.
The Blocklist Has Grown Up From Optional Hardening Into Real Policy
When Microsoft introduced the vulnerable driver blocklist into the Windows Security experience, it was easy to treat it as another security toggle for enthusiasts. It sat near features such as Memory Integrity, and many users saw it as part of the broader Core Isolation push: useful, probably good, but not always compatible with old hardware and old utilities.That era is ending. The blocklist is now part of the routine servicing story, and the April 2026 updates show what that means in practice. A cumulative update does not merely patch Microsoft code; it can change which third-party kernel components Windows will tolerate. That is a powerful lever, and Microsoft is increasingly willing to pull it.
The logic is defensible. Attackers have learned that vulnerable signed drivers are a useful way to reach the kernel without writing a malicious driver from scratch. Security products can be disabled, tamper protections bypassed, and protected processes attacked once kernel execution is in play. Leaving known vulnerable drivers loadable because someone might still use an old utility is a compatibility policy, not a security policy.
Still, the enterprise impact is real. Backup software is not a game overlay or an RGB controller. It sits in the disaster-recovery path. If an update breaks the ability to mount images, that affects restore testing, audit confidence, ransomware recovery planning, and the basic promise that yesterday’s backup can become today’s rescue.
The uncomfortable truth is that Microsoft is pushing the Windows ecosystem toward a stricter model faster than some operational habits can follow. That is not necessarily wrong. It does mean that every driver-bearing utility now has to be treated like privileged infrastructure, not like an ordinary app that can be updated whenever someone remembers.
Backup Software Lives in the Same Dangerous Neighborhood as Malware
There is a reason backup applications keep appearing in uncomfortable security stories. To do their job well, they need powers that malware would love to have. They inspect disks, snapshot volumes, read locked files, mount images, interact with boot environments, and sometimes protect their own files from tampering. The difference between a backup tool and an attacker’s toolkit is intent, signing, and control.That makes backup software a natural pressure point for modern Windows security. The kernel does not know that a user likes Macrium Reflect or that a technician trusts a particular imaging workflow. It sees code requesting privileged execution. If that code matches a known vulnerable driver rule, the trust conversation is over.
This is where some users will accuse Microsoft of being heavy-handed, and there is a fair emotional case for that complaint. A person trying to recover a file from a backup does not feel safer when Windows blocks the tool they need. They feel trapped between an update they did not fully understand and a restore workflow that no longer behaves.
But the alternative is worse. If Microsoft maintains compatibility with old vulnerable kernel drivers indefinitely, attackers get the benefit too. They do not need to persuade victims to run Macrium Reflect. They need only bring a vulnerable signed driver along for the ride, if the system will still load it. The same machinery that lets a backup utility mount an image can, when flawed, become a path to system compromise.
That is why “just let me override it” is not a satisfying answer at scale. A consumer power user may be willing to accept the risk for a one-off restore. A managed fleet cannot build its security posture around thousands of one-off exceptions to kernel driver enforcement. Once a driver is known to be dangerous, the burden should shift to the vendor and the administrator to deploy a safe version, not to the OS to keep trusting the unsafe one.
The April Patch Already Had Enough Drama
The backup-app issue does not land in isolation. KB5083769 has already attracted attention for other known issues, including BitLocker recovery prompts on certain systems with an unsupported or unrecommended policy configuration, and Remote Desktop warning display problems that Microsoft addressed in KB5083631. For a Patch Tuesday update, that is not unprecedented, but it adds to the perception that April 2026 was unusually eventful for Windows administrators.The BitLocker issue is especially relevant because it shows the same broader pattern: Microsoft is tightening security assumptions around boot and trust, and edge-case configurations are feeling the squeeze. Devices with particular BitLocker PCR policy settings and Secure Boot certificate conditions may be asked for a recovery key after the update. Microsoft’s guidance frames that as a limited scenario, but for the unlucky administrator, “limited” still means a ticket queue.
The Remote Desktop warning issue is a different species of problem, more interface than enforcement. Microsoft changed how
.rdp files are presented to reduce phishing risk, then had to fix cases where the warning dialog did not render correctly on mixed-DPI monitor setups. Even there, the story is familiar: a security improvement collides with the messiness of real Windows deployments.Put together, April’s update cycle looks like a preview of where Windows servicing is headed. Updates are no longer just collections of bug fixes and CVE patches. They are policy delivery vehicles. They change trust decisions, harden old pathways, and make previously tolerated configurations visible by breaking them.
For enthusiasts, that means reading Patch Tuesday notes with more skepticism and more attention. For enterprises, it means rings, pilots, rollback planning, and restore testing are not bureaucratic rituals. They are the only way to discover whether a security hardening change has just intersected with a critical operational dependency.
The Right Fix Is Not to Uninstall the Update
Uninstalling KB5083769 may appear to fix the immediate problem for some users, because it can remove the enforcement change that blocks the driver. That does not make it the right fix. It merely reopens the security hole that the update closed, while also removing unrelated April security patches.The better path is to update the affected backup software and confirm that the vulnerable driver is no longer present or no longer being loaded. In the Macrium case, that means ensuring Reflect is on a version with the patched
psmounterex.sys driver and checking whether any stale copy remains in the driver store or application directories. For managed environments, it also means inventorying backup agents, RMM backup modules, rescue media, and any automation that silently installs older components.Administrators should treat Event ID 3077 in the Code Integrity Operational log as the starting point. If the event names
psmounterex.sys, the problem is no longer speculative. From there, the practical workflow is to identify which product installed it, update or remove that product, reboot where necessary, and retest the mount operation.There is also a subtle but crucial distinction between backup creation and image mounting. Microsoft notes that full image backup creation may still succeed while image-mount operations fail. That split can lull users into a dangerous confidence: scheduled backups may report success, while the ability to browse or restore from those images through the usual interface is broken.
That is why backup verification has to include restore-path testing, not just “job completed” status. A backup that cannot be mounted during an incident is not necessarily useless, but it is less useful than the dashboard suggests. The April update is a reminder that recovery is a workflow, not a file.
Vendors Now Need to Prove Their Drivers Age Gracefully
Microsoft will take most of the heat because Windows is the thing saying no, but backup vendors cannot pretend this is solely an operating-system problem. If a commercial backup product installs a kernel driver, the vendor owns the lifecycle of that driver. That includes patching vulnerabilities, removing old binaries, documenting remediation steps, and making failure states intelligible.Macrium appears to have patched CVE-2023-43896 in 2023, which is exactly what vendors should do. But patching is only one part of the story. The harder question is whether every supported upgrade path reliably removes or supersedes the vulnerable component, whether the product can detect a blocked driver condition, and whether customers on old builds receive unavoidable warnings before Windows enforcement turns the issue into a restore failure.
The same standard should apply to every backup vendor. Acronis, NinjaOne, UrBackup, and others have been mentioned in user reports around the April update cycle, though the Microsoft support note specifically names
psmounterex.sys. The broader category is what matters: any backup product that depends on kernel components has to assume those components will be judged by the operating system’s security policy, not merely by whether they worked yesterday.There is a business-model lesson here too. Perpetual licenses and frozen utility versions are attractive to users, but kernel-adjacent software is a poor place for permanent stasis. A PDF reader can be old and annoying. A kernel driver that is old and vulnerable is a platform risk. Vendors that sell system-level utilities need update channels and support expectations that match that reality.
For WindowsForum readers who maintain family PCs, home labs, or small-business fleets, this is the practical shift: treat backup software like firmware or endpoint security, not like a one-time utility purchase. If it installs a driver, it belongs in the patch calendar.
Microsoft Also Owes Admins a Cleaner Blast Radius
Security hardening is easier to defend when it is predictable. Microsoft has a difficult job balancing compatibility against known driver risk, and its own documentation acknowledges that blocking drivers can break devices or software. The company also says it sometimes holds back blocks to avoid breaking functionality while partners move customers to patched versions.That balancing act is exactly why communication matters. If a vulnerable driver block is likely to affect backup software, administrators need advance notice, clear detection scripts, and precise remediation guidance. A support article after the fact is useful, but it should not be the first moment the issue becomes visible to the people responsible for recovery systems.
The Windows release health dashboard has improved over the years, but driver blocklist changes remain an awkward fit for standard KB notes. They are security changes, compatibility changes, and operational changes all at once. The average user will not read them. The average administrator may read them only after a pilot machine fails.
Microsoft could reduce the damage with better preflight tooling. Imagine Windows Update for Business reporting that a device has a driver scheduled to be blocked by the next cumulative update. Imagine Intune surfacing “vulnerable driver dependency detected” as a readiness signal. Imagine Event Viewer being supplemented by a Windows Security notification that names the blocked driver, the affected application, and the vendor update path.
None of that weakens security. It makes security enforceable without turning restore testing into archaeology. The problem with the April backup failures is not that Microsoft blocked a vulnerable driver. It is that too many users will discover the block only after the restore workflow starts failing.
The April Block Is a Warning Shot for the Windows Utility Ecosystem
The most tempting reading of this story is narrow: Macrium users hit a problem after KB5083769 and KB5083631 because Windows blockedpsmounterex.sys. That reading is true, but it is too small. The larger story is that the Windows utility ecosystem is being forced out of the permissive driver era.For decades, Windows tolerated an enormous range of third-party kernel code in the name of compatibility. That tolerance helped build a rich ecosystem of backup tools, disk utilities, hardware monitors, fan controllers, anti-cheat systems, VPN clients, encryption products, and security agents. It also created a sprawling attack surface where old signed drivers could linger long after their flaws were known.
The modern Windows security model is less sentimental. Memory Integrity, Smart App Control, vulnerable driver blocking, attack surface reduction rules, and App Control policies all point in the same direction. Trust is becoming more conditional, more revocable, and more centrally enforced.
That will create friction. Some beloved tools will need rewrites. Some old utilities will become unusable. Some vendors will discover that “signed” is not the same thing as “safe.” Users who have built disaster-recovery habits around aging software will have to modernize those habits before the next incident modernizes them by force.
Still, the direction is right. Kernel integrity is not an optional luxury in a world where ransomware crews, credential thieves, and commodity malware increasingly look for ways to disable defenses from below the operating system’s normal guardrails. If Windows cannot say no to known vulnerable drivers, every other security promise gets weaker.
The Restore Test Is Now Part of Patch Management
The concrete lesson from KB5083769 is not that users should distrust Windows Update or abandon third-party backup software. It is that patch management and recovery testing have become the same conversation. A system is not “patched” in any meaningful operational sense if the update silently breaks the path to restore it.Most organizations already know this in theory. Few practice it rigorously on endpoints, especially where backup tools are decentralized or managed by MSPs. April’s driver block gives that theory a very specific shape.
- Administrators should check the Code Integrity Operational log for Event ID 3077 when backup image mounting fails after the April 14, 2026 Windows updates.
- Users should update Macrium Reflect or any affected backup product before assuming that VSS itself is the root cause of the failure.
- Backup creation may still succeed even when image mounting or browsing fails, so restore-path testing is necessary after applying KB5083769 or KB5083631.
- Removing the Windows security update may restore compatibility temporarily, but it also removes security protections and should not be treated as the primary fix.
- Any backup or disk utility that installs a kernel driver should be included in normal vulnerability management, software inventory, and patch validation.
- Vendors need to make blocked-driver failures explicit in their applications instead of letting users chase misleading snapshot or timeout errors.
Windows is becoming less willing to carry old privileged code for the sake of convenience, and that change will keep surprising anyone who treats drivers as invisible plumbing. The right response is not to romanticize the old looseness or curse every hardening change that breaks a workflow. It is to build backup practices, vendor update habits, and deployment rings around the reality that security policy now reaches all the way into the restore button — and the next blocklist update will not wait for a disaster-recovery window to make that clear.
Source: Neowin Microsoft: Windows 11 KB5083769, KB5083631 block backup apps like Macrium, here's why