Code Integrity (Memory Integrity/HVCI) blocks an MSIX app's own bundled DLL (vk_swiftshader.dll) - permanent fix beyond reinstalling?

Welcome to Microsoft Q&A!

Thank you for sharing the details information.

Based on the behavior you have described, reinstalling the MSIX package is a reasonable recovery step because it restores the package's original signed contents. However, it may not be a permanent solution if the same bundled DLL continues to fail Code Integrity validation.

One important point is that Event ID 3033 alone does not necessarily mean that Memory Integrity (HVCI) directly blocked the DLL. Event 3033 can occur for several reasons, including:

• The file's signature has been revoked.
• The file contains an expired signature that uses the Lifetime Signing EKU.
• A process protected by Code Integrity Guard (CIG) attempts to load a DLL that does not meet its signing requirements.
• An enforced App Control policy does not trust the binary. In these cases, Event 3033 is typically accompanied by Event 3077, while Event 3089 provides additional signature information.

Because of this, the next step is to determine exactly which policy or validation requirement is causing the rejection.

1. Recommended validation

In Event Viewer, review:

Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational

Then correlate the Event 3033 entry with the following related events:

• 3077 – Indicates a file was blocked by an enforced App Control policy.
• 3089 – Provides detailed signing information for the DLL.
• 3036 – Indicates that the signing certificate has been revoked.
• 3074 – Indicates a page hash validation failure while HVCI is enabled.

If available, you can capture the Policy ID from Event 3077 and review the signature details reported in Event 3089. These events can help determine whether the issue is caused by App Control policy enforcement, certificate revocation or expiration, Code Integrity Guard requirements, or another platform protection mechanism.

2. Is there a supported exclusion?

The answer depends on which security feature is enforcing the block:

• Smart App Control does not currently provide a per-application allow list or exclusion mechanism, to obtain a properly signed version of the application from the vendor or disable Smart App Control, which reduces security protection.
• App Control for Business (WDAC) may allow administrators to create appropriate signer, publisher, file attribute, or hash-based allow rules. However, this is an administrative policy decision rather than a general HVCI exception.
• Code Integrity Guard (CIG) or platform-level signing requirements generally require the application to load binaries that meet the necessary signing level. In these scenarios, a local exception may not be effective.

3. Should the DLL be manually re-signed?

Generally, no. Modifying or re-signing a DLL inside an installed MSIX package changes the package contents and can cause Windows to treat the package as modified or tampered with. MSIX package integrity protections are specifically designed to detect these changes and may trigger remediation or repair workflows.

For that reason, if the original vk_swiftshader.dll does not satisfy the applicable signing or policy requirements, the long-term fix typically needs to come from the application publisher. This would usually involve:

• Identifying the exact validation failure using Events 3033, 3077, and 3089.
• Rebuilding or replacing the affected DLL if necessary.
• Signing the binary using the appropriate code-signing requirements.
• Rebuilding and re-signing the complete MSIX package.
• Testing the updated package with HVCI, Smart App Control, and other relevant security protections enabled.

Currently, there is no documented Windows-side exclusion specifically intended to bypass Code Integrity validation for a bundled MSIX DLL that fails HVCI/App Control requirements. If the DLL is being rejected because of its signature state or signing level, the durable remediation generally needs to come from the application vendor rather than from Windows itself.

If the issue continues to occur, I would recommend collecting the correlated 3033, 3077, and 3089 events, along with the Policy ID, package version, and DLL hash, and sharing those details with the application publisher. If the responsible policy still cannot be identified, opening a Microsoft Support case would be the best way to perform a deeper investigation.

Additionally, if the same behavior can be reproduced on a clean Windows installation with no custom App Control or WDAC policies configured, you may also consider submitting feedback through Feedback Hub for further analysis.

References:

Understanding App Control event IDs | Microsoft Learn

App Control for Business and virtualization-based code integrity | Microsoft Learn

Understanding App Control event IDs | Microsoft Learn

Smart App Control Frequently Asked Questions | Microsoft Support

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.