Microsoft’s April 14, 2026 Windows security updates, including KB5083769 and the later KB5083631 preview, are blocking the psmounterex.sys kernel driver used by some backup tools to mount disk images on Windows 11 systems. The newly public registry workaround is therefore real, but it is also the wrong lesson to take from the incident. Microsoft has not merely “broken Macrium”; it has reminded everyone that backup software is now part of the Windows attack surface. The uncomfortable truth is that a tool designed to save a machine can also become one of the most privileged ways to compromise it.
The driver at the center of the mess, psmounterex.sys, is not a random helper DLL or a misbehaving tray app. It is a kernel-mode component used by older Macrium Reflect releases to mount backup images as virtual drives, giving users the familiar ability to browse, copy, and restore files from an image as though it were another disk in Explorer. That convenience depends on exactly the kind of deep system access Microsoft has spent the last several years trying to make less casual.
After installing Windows updates released on or after April 14, 2026, affected users can see image mounting fail, browsing or restore operations time out, and Code Integrity events reporting that Windows blocked the driver from loading. Microsoft’s own support language is blunt: this is intentional behavior, not an accidental regression. The psmounterex.sys driver is on the Microsoft vulnerable driver blocklist, and it is expected to remain there.
That distinction matters. A normal Windows update bug is an engineering failure: something shipped, something broke, and a fix rolls out later. This is closer to a policy collision. Microsoft’s kernel security policy has decided that a driver used by real backup workflows carries enough risk that Windows should refuse to load vulnerable versions, even when the result is a broken restoration workflow for paying customers.
The timing makes the story worse for administrators. Backup problems do not always reveal themselves on patch Tuesday morning. Many users create images automatically and only mount them days or weeks later, when they need to recover a file, test a restore, or migrate a machine. A patch that interferes with mounting backup images can sit quietly until the moment the user most needs the backup chain to work.
That explains why the workaround appears attractive. If your immediate problem is that Macrium Reflect 8.1 can no longer mount an image, and the blocked component is the reason, disabling the blocklist can restore the missing functionality long enough to get files out of a backup. For a home user in a bind, that can feel like a pragmatic rescue hatch. For a sysadmin with users waiting, it can feel like oxygen.
But the registry change does not make the driver safe. It tells Windows to stop checking a list that exists because attackers increasingly abuse signed, legitimate, but vulnerable drivers to reach the kernel. This is the classic bring-your-own-vulnerable-driver problem: malware does not need to smuggle an obviously malicious driver past every defense if it can lean on a trusted vendor’s signed component with a known flaw.
The most responsible version of the workaround is narrow, temporary, and reversible. Use it only on a machine you control, only for the duration needed to mount or recover data, and switch the value back afterward. Even then, it is not a clean fix; it is a controlled weakening of the operating system’s defenses to recover from a compatibility break.
That is why the registry hack is the wrong protagonist for this story. The command is not clever. It is a doorstop. The interesting question is why so much practical backup functionality still depends on kernel components that can be bricked by a security policy update.
For years, users treated those components as plumbing. The backup suite installed a driver; the driver loaded; images mounted; nobody cared unless the machine blue-screened. But Windows security has changed around that assumption. Kernel-mode code is no longer treated as a quiet implementation detail. It is increasingly treated as a boundary that vendors must justify crossing.
Microsoft’s vulnerable driver blocklist is part of that shift. Since the Windows 11 2022 Update, Microsoft has enabled the blocklist by default on Windows 11 devices, and it is also enforced in scenarios involving Memory Integrity, Smart App Control, or S mode. The company has made the argument repeatedly: attackers exploit weaknesses in legitimate signed drivers because kernel access is so valuable.
In that world, “but this driver belongs to my backup program” is not a sufficient defense. A signed driver with a known vulnerability is still a signed driver with a known vulnerability. A backup product may be benign, but the driver’s capabilities can be repurposed by malicious code once it is present and loadable.
This is where the user frustration and Microsoft’s security logic talk past each other. Users see a trusted product failing after an update. Microsoft sees a vulnerable kernel component being blocked according to a published hardening strategy. Both are correct, which is why the situation is so irritating.
That detail changes the story from “Microsoft broke Macrium” to “Microsoft broke a legacy compatibility path that Macrium has already moved away from.” It does not absolve Microsoft of responsibility for how abruptly customers experience the change, but it does suggest the long-term answer is not to keep disabling Windows security. The answer is to get onto software that no longer depends on the blocked component.
The awkward part is that many users do not upgrade backup tools on the same cadence as browsers or chat clients. Backup software is supposed to be boring. If it works, people leave it alone, precisely because changing it feels risky. In enterprise environments, backup agents may be baked into images, recovery runbooks, compliance workflows, and licensing agreements that are not casually revised because a new major version exists.
That creates a dangerous lag between vendor remediation and customer reality. A vendor can patch or rearchitect; Microsoft can update its blocklist; attackers can study the public CVE; but thousands of systems may continue running the older code path because nobody wants to touch the backup stack. The least glamorous software in the fleet becomes the hardest to modernize.
Macrium users now have a visible forcing function. Reflect X avoids this specific driver dependency, while affected Reflect 8.1 users must either wait for vendor guidance, alter Windows security policy temporarily, or change versions. None of those choices is as pleasant as “install the update and carry on,” but that era is ending for software that lives near the kernel.
For users, the distinction may feel academic. A backup fails, an update preceded it, and the answer is to restore working protection. But for IT teams, conflating every April backup failure into a single cause is a recipe for bad remediation. A VSS timeout during snapshot creation is not the same operational failure as an image-mounting driver being blocked by Code Integrity.
The psmounterex.sys case is unusually crisp because Microsoft has documented the behavior and tied it to a known vulnerable driver. The symptom set includes failures to mount backup image files as virtual drives and Code Integrity events showing the driver block. That points to the vulnerable driver blocklist. If the error is a VSS snapshot timeout during backup creation, the diagnostic path may lead elsewhere.
This matters because the registry workaround is being discussed as though it were a universal cure. It is not. Disabling the vulnerable driver blocklist may help a machine whose backup image mounting depends on a blocked driver, but it should not be treated as a general-purpose fix for every backup application that misbehaves after KB5083769. Applying it blindly expands risk without proving it addresses the failure.
Administrators should be precise here. Check the backup product version, confirm whether psmounterex.sys is present or being loaded, inspect Code Integrity logs, and separate image mounting failures from snapshot creation failures. The temptation after a patch regression is to find one magic command. The professional response is to build a small evidence chain before changing a security control.
It also left Microsoft with an enormous compatibility debt. Every time Windows tightens a kernel rule, blocks an old driver, changes an installation path, or enforces a new trust policy, some non-trivial workflow breaks. The company can test against major partners, but the Windows ecosystem is too broad and too weird to anticipate every interaction.
The vulnerable driver blocklist is a particularly sensitive instrument because it sits at the intersection of security and trust. Microsoft is not saying “this app is unwanted.” It is saying “this driver should not load.” To a user, the distinction disappears when the app stops working. To a security engineer, it is the difference between blocking a vulnerable primitive and banning a product.
That tension will only intensify as Microsoft leans harder into virtualization-based security, memory integrity, Smart App Control, and application control policies for business. The model is moving from “signed code can run” toward “signed code must also be acceptable, current, and policy-compliant.” That is a healthier model for security, but a rougher model for the old Windows habit of letting everything coexist.
The irony is that backup vendors have long marketed themselves as insurance against Microsoft’s own update failures. When an update breaks boot, trashes a profile, or triggers BitLocker recovery, users reach for their image backup. Now a Microsoft security update has impaired part of the backup workflow itself. That is the kind of circular dependency that makes IT pros swear at both vendors at once.
But security teams have spent years asking platform vendors to do exactly this kind of thing. Do not merely publish guidance. Do not rely on users to audit driver inventories. Do not allow known-vulnerable signed kernel components to keep loading forever because compatibility is politically easier. Enforce the boundary.
That enforcement necessarily creates losers. The losing party may be a vendor with legacy code, an admin with an aging deployment, or a home user who only discovers the problem when trying to recover a folder. The blocklist does not care that the driver has been sitting quietly on a machine for years. Once Windows policy says the driver is blocked, the user’s intent is no longer enough to load it.
The challenge for Microsoft is not whether vulnerable drivers should be blocked. They should. The challenge is how to make the blast radius legible before users are in a recovery scenario. A backup product is not a game overlay or RGB utility. If Microsoft knows a driver block will impair image mounting for a popular backup tool, the communication bar should be higher than a support article many affected users will only find after the fact.
This is where Windows Update still feels too blunt. Security hardening ships through the same channel as reliability fixes and monthly cumulative updates, and users experience it as one opaque event. A driver blocklist change that affects backup recovery deserves prominent health dashboard visibility, vendor-specific notices where appropriate, and clearer pre-deployment signals for managed environments.
For organizations, the answer is less comfortable. You need to know which backup agents, disk tools, encryption utilities, security products, and hardware management suites install kernel drivers across the fleet. You need to know their versions. You need a way to test Microsoft’s driver blocklist changes before they hit production machines that support recovery workflows.
That is not glamorous work. It is also increasingly unavoidable. The Windows endpoint is now a policy-enforced platform where vulnerable drivers may be blocked regardless of whether the dependent application is business-critical. If your backup process requires a driver Microsoft has decided is unsafe, your recovery plan contains a hidden dependency on Microsoft’s tolerance.
A more mature response would be to add driver blocklist validation to patch testing. Not just “does Windows boot?” and “does the VPN connect?” but “can we create a backup, mount an image, browse it, restore a file, and perform a bare-metal recovery test using the patched OS?” Many organizations say they test backups. Fewer test the full restore path under the latest security baseline.
The registry workaround should therefore be documented, if at all, as an emergency exception with an expiration. It should not become tribal admin lore passed around as the permanent fix for Microsoft being annoying. Every time a security control is disabled for convenience and never re-enabled, the organization buys short-term uptime with long-term exposure.
Source: Neowin Registry hack lets you bypass Windows 11 KB5083769, KB5083631 patch that blocks some apps
Microsoft Did Not Trip Over Macrium So Much as Step on a Landmine
The driver at the center of the mess, psmounterex.sys, is not a random helper DLL or a misbehaving tray app. It is a kernel-mode component used by older Macrium Reflect releases to mount backup images as virtual drives, giving users the familiar ability to browse, copy, and restore files from an image as though it were another disk in Explorer. That convenience depends on exactly the kind of deep system access Microsoft has spent the last several years trying to make less casual.After installing Windows updates released on or after April 14, 2026, affected users can see image mounting fail, browsing or restore operations time out, and Code Integrity events reporting that Windows blocked the driver from loading. Microsoft’s own support language is blunt: this is intentional behavior, not an accidental regression. The psmounterex.sys driver is on the Microsoft vulnerable driver blocklist, and it is expected to remain there.
That distinction matters. A normal Windows update bug is an engineering failure: something shipped, something broke, and a fix rolls out later. This is closer to a policy collision. Microsoft’s kernel security policy has decided that a driver used by real backup workflows carries enough risk that Windows should refuse to load vulnerable versions, even when the result is a broken restoration workflow for paying customers.
The timing makes the story worse for administrators. Backup problems do not always reveal themselves on patch Tuesday morning. Many users create images automatically and only mount them days or weeks later, when they need to recover a file, test a restore, or migrate a machine. A patch that interferes with mounting backup images can sit quietly until the moment the user most needs the backup chain to work.
The Registry Hack Works Because It Turns Off the Guardrail
The workaround now circulating is simple enough to be dangerous. Running an elevated command that setsVulnerableDriverBlocklistEnable to 0 under the Code Integrity configuration disables the vulnerable driver blocklist, and a reboot lets the previously blocked driver load again. In plain English, Windows stops enforcing one of the mechanisms designed to prevent known-bad kernel drivers from entering the system.That explains why the workaround appears attractive. If your immediate problem is that Macrium Reflect 8.1 can no longer mount an image, and the blocked component is the reason, disabling the blocklist can restore the missing functionality long enough to get files out of a backup. For a home user in a bind, that can feel like a pragmatic rescue hatch. For a sysadmin with users waiting, it can feel like oxygen.
But the registry change does not make the driver safe. It tells Windows to stop checking a list that exists because attackers increasingly abuse signed, legitimate, but vulnerable drivers to reach the kernel. This is the classic bring-your-own-vulnerable-driver problem: malware does not need to smuggle an obviously malicious driver past every defense if it can lean on a trusted vendor’s signed component with a known flaw.
The most responsible version of the workaround is narrow, temporary, and reversible. Use it only on a machine you control, only for the duration needed to mount or recover data, and switch the value back afterward. Even then, it is not a clean fix; it is a controlled weakening of the operating system’s defenses to recover from a compatibility break.
That is why the registry hack is the wrong protagonist for this story. The command is not clever. It is a doorstop. The interesting question is why so much practical backup functionality still depends on kernel components that can be bricked by a security policy update.
Backup Software Has Been Living in the Kernel’s Shadow
Disk imaging software has always occupied a privileged place in Windows. It needs to inspect volumes, coordinate snapshots, read locked files, preserve metadata, and sometimes perform restore operations below the comfort layer of ordinary user-mode applications. That is why backup vendors have historically relied on drivers, services, filters, and integrations with Volume Shadow Copy Service.For years, users treated those components as plumbing. The backup suite installed a driver; the driver loaded; images mounted; nobody cared unless the machine blue-screened. But Windows security has changed around that assumption. Kernel-mode code is no longer treated as a quiet implementation detail. It is increasingly treated as a boundary that vendors must justify crossing.
Microsoft’s vulnerable driver blocklist is part of that shift. Since the Windows 11 2022 Update, Microsoft has enabled the blocklist by default on Windows 11 devices, and it is also enforced in scenarios involving Memory Integrity, Smart App Control, or S mode. The company has made the argument repeatedly: attackers exploit weaknesses in legitimate signed drivers because kernel access is so valuable.
In that world, “but this driver belongs to my backup program” is not a sufficient defense. A signed driver with a known vulnerability is still a signed driver with a known vulnerability. A backup product may be benign, but the driver’s capabilities can be repurposed by malicious code once it is present and loadable.
This is where the user frustration and Microsoft’s security logic talk past each other. Users see a trusted product failing after an update. Microsoft sees a vulnerable kernel component being blocked according to a published hardening strategy. Both are correct, which is why the situation is so irritating.
Macrium Reflect X Shows the Exit Route, Not the Excuse
Macrium’s own support comments sharpen the point. Version X reportedly does not use psmounterex.sys, which is why it is not affected in the same way. The issue appears to hit Version 8.1 users who installed the latest Windows 11 update and still rely on the older driver path for image mounting.That detail changes the story from “Microsoft broke Macrium” to “Microsoft broke a legacy compatibility path that Macrium has already moved away from.” It does not absolve Microsoft of responsibility for how abruptly customers experience the change, but it does suggest the long-term answer is not to keep disabling Windows security. The answer is to get onto software that no longer depends on the blocked component.
The awkward part is that many users do not upgrade backup tools on the same cadence as browsers or chat clients. Backup software is supposed to be boring. If it works, people leave it alone, precisely because changing it feels risky. In enterprise environments, backup agents may be baked into images, recovery runbooks, compliance workflows, and licensing agreements that are not casually revised because a new major version exists.
That creates a dangerous lag between vendor remediation and customer reality. A vendor can patch or rearchitect; Microsoft can update its blocklist; attackers can study the public CVE; but thousands of systems may continue running the older code path because nobody wants to touch the backup stack. The least glamorous software in the fleet becomes the hardest to modernize.
Macrium users now have a visible forcing function. Reflect X avoids this specific driver dependency, while affected Reflect 8.1 users must either wait for vendor guidance, alter Windows security policy temporarily, or change versions. None of those choices is as pleasant as “install the update and carry on,” but that era is ending for software that lives near the kernel.
The VSS Confusion Makes the Blast Radius Look Bigger
Part of the reporting around KB5083769 has also centered on broader backup failures involving Volume Shadow Copy Service timeouts, with products such as Acronis Cyber Protect Cloud, NinjaOne Backup, and UrBackup Server appearing in user reports. That has blurred two related but not identical narratives: one about psmounterex.sys being blocked, and another about backup operations failing after the April Windows update.For users, the distinction may feel academic. A backup fails, an update preceded it, and the answer is to restore working protection. But for IT teams, conflating every April backup failure into a single cause is a recipe for bad remediation. A VSS timeout during snapshot creation is not the same operational failure as an image-mounting driver being blocked by Code Integrity.
The psmounterex.sys case is unusually crisp because Microsoft has documented the behavior and tied it to a known vulnerable driver. The symptom set includes failures to mount backup image files as virtual drives and Code Integrity events showing the driver block. That points to the vulnerable driver blocklist. If the error is a VSS snapshot timeout during backup creation, the diagnostic path may lead elsewhere.
This matters because the registry workaround is being discussed as though it were a universal cure. It is not. Disabling the vulnerable driver blocklist may help a machine whose backup image mounting depends on a blocked driver, but it should not be treated as a general-purpose fix for every backup application that misbehaves after KB5083769. Applying it blindly expands risk without proving it addresses the failure.
Administrators should be precise here. Check the backup product version, confirm whether psmounterex.sys is present or being loaded, inspect Code Integrity logs, and separate image mounting failures from snapshot creation failures. The temptation after a patch regression is to find one magic command. The professional response is to build a small evidence chain before changing a security control.
Microsoft’s Security Posture Is Finally Colliding With Windows’ Compatibility Culture
Windows became the dominant desktop operating system partly because it tolerated a vast ecosystem of drivers, utilities, add-ons, shell extensions, and management agents. That tolerance was a strength for decades. It let hardware makers, backup vendors, antivirus companies, VPN providers, disk tools, and niche enterprise software integrate deeply enough to solve real problems.It also left Microsoft with an enormous compatibility debt. Every time Windows tightens a kernel rule, blocks an old driver, changes an installation path, or enforces a new trust policy, some non-trivial workflow breaks. The company can test against major partners, but the Windows ecosystem is too broad and too weird to anticipate every interaction.
The vulnerable driver blocklist is a particularly sensitive instrument because it sits at the intersection of security and trust. Microsoft is not saying “this app is unwanted.” It is saying “this driver should not load.” To a user, the distinction disappears when the app stops working. To a security engineer, it is the difference between blocking a vulnerable primitive and banning a product.
That tension will only intensify as Microsoft leans harder into virtualization-based security, memory integrity, Smart App Control, and application control policies for business. The model is moving from “signed code can run” toward “signed code must also be acceptable, current, and policy-compliant.” That is a healthier model for security, but a rougher model for the old Windows habit of letting everything coexist.
The irony is that backup vendors have long marketed themselves as insurance against Microsoft’s own update failures. When an update breaks boot, trashes a profile, or triggers BitLocker recovery, users reach for their image backup. Now a Microsoft security update has impaired part of the backup workflow itself. That is the kind of circular dependency that makes IT pros swear at both vendors at once.
The Patch Is Doing What Security Teams Asked For
It is tempting to frame Microsoft as the villain because the user-visible outcome is ugly. Someone installed a Windows update and lost the ability to mount a backup image. That is an immediate, concrete failure, while the risk of a vulnerable driver being exploited can feel abstract. The broken workflow has a face; the prevented attack does not.But security teams have spent years asking platform vendors to do exactly this kind of thing. Do not merely publish guidance. Do not rely on users to audit driver inventories. Do not allow known-vulnerable signed kernel components to keep loading forever because compatibility is politically easier. Enforce the boundary.
That enforcement necessarily creates losers. The losing party may be a vendor with legacy code, an admin with an aging deployment, or a home user who only discovers the problem when trying to recover a folder. The blocklist does not care that the driver has been sitting quietly on a machine for years. Once Windows policy says the driver is blocked, the user’s intent is no longer enough to load it.
The challenge for Microsoft is not whether vulnerable drivers should be blocked. They should. The challenge is how to make the blast radius legible before users are in a recovery scenario. A backup product is not a game overlay or RGB utility. If Microsoft knows a driver block will impair image mounting for a popular backup tool, the communication bar should be higher than a support article many affected users will only find after the fact.
This is where Windows Update still feels too blunt. Security hardening ships through the same channel as reliability fixes and monthly cumulative updates, and users experience it as one opaque event. A driver blocklist change that affects backup recovery deserves prominent health dashboard visibility, vendor-specific notices where appropriate, and clearer pre-deployment signals for managed environments.
The Real Fix Is Inventory, Not Internet Folklore
For home users, the practical path is relatively straightforward. If you are on Macrium Reflect 8.1 and suddenly cannot mount images after KB5083769 or KB5083631, check Macrium’s current guidance and strongly consider moving to a version that does not depend on psmounterex.sys. If you must use the registry workaround to retrieve data, treat it like booting into a less secure recovery mode, not like a tweak to leave in place.For organizations, the answer is less comfortable. You need to know which backup agents, disk tools, encryption utilities, security products, and hardware management suites install kernel drivers across the fleet. You need to know their versions. You need a way to test Microsoft’s driver blocklist changes before they hit production machines that support recovery workflows.
That is not glamorous work. It is also increasingly unavoidable. The Windows endpoint is now a policy-enforced platform where vulnerable drivers may be blocked regardless of whether the dependent application is business-critical. If your backup process requires a driver Microsoft has decided is unsafe, your recovery plan contains a hidden dependency on Microsoft’s tolerance.
A more mature response would be to add driver blocklist validation to patch testing. Not just “does Windows boot?” and “does the VPN connect?” but “can we create a backup, mount an image, browse it, restore a file, and perform a bare-metal recovery test using the patched OS?” Many organizations say they test backups. Fewer test the full restore path under the latest security baseline.
The registry workaround should therefore be documented, if at all, as an emergency exception with an expiration. It should not become tribal admin lore passed around as the permanent fix for Microsoft being annoying. Every time a security control is disabled for convenience and never re-enabled, the organization buys short-term uptime with long-term exposure.
The April Backup Breakage Has a Message for Every Windows Shop
This incident is annoying because it is not just a bug, and it is alarming because it touches recovery tooling. The useful response is to reduce the surprise next time Microsoft tightens the kernel gate.- Systems running affected Windows updates from April 14, 2026 onward may block vulnerable versions of psmounterex.sys, preventing some backup image mounting workflows from working normally.
- The registry workaround that disables
VulnerableDriverBlocklistEnablecan restore blocked-driver behavior, but it weakens a Windows security protection and should be temporary if used at all. - Macrium Reflect X reportedly avoids this specific issue because it does not use psmounterex.sys, while Reflect 8.1 users are the group most clearly associated with the mounting failure.
- Backup creation failures involving VSS timeouts should not automatically be treated as the same problem as psmounterex.sys image-mounting failures.
- IT teams should test backup creation, image mounting, file-level restore, and full recovery after Windows security updates, not merely confirm that the backup agent launches.
- Driver inventory is now part of backup resilience because a signed kernel driver can be both operationally useful and security-disallowed.
Source: Neowin Registry hack lets you bypass Windows 11 KB5083769, KB5083631 patch that blocks some apps