Interactive Troubleshooter

Published: Sep 18, 2026

Windows Credential Guard Blocking App: Exclusion Guide

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Exhaustive technical troubleshooting guide for resolving application blocking, credential delegation failures, and driver conflicts caused by Windows Credential Guard and Virtualization-Based Security (VBS). Learn how to identify LSA Protected Process Light (PPL) violations, audit unauthenticated memory access, and reconfigure authentication protocols.

Full Diagnostic Tree & Step-by-Step Overview

What specific error or application failure are you experiencing with Windows Credential Guard enabled?

Legacy app authentication fails, returns logon error 0xC000006D, or refuses domain credentials
Custom Security Support Provider (SSP/AP) or SSO plugin fails to load into LSASS
Antivirus, EDR agent, or diagnostic tool fails with STATUS_ACCESS_DENIED (0xC000022) when opening LSASS
Third-party hypervisor, VPN software, or system driver crashes/BSOD when VBS is active

Which specific authentication protocol or credential delegation scenario is failing?

App relies on WDigest or cached plaintext password extraction in LSASS memory
App requires NTLMv1 or Unconstrained Kerberos Delegation across domain boundaries
Kerberos ticket requests fail due to DES/RC4 encryption suite restrictions
Remote Desktop (RDP) or remote management app fails credential delegation

Remediating WDigest and Plaintext Credential Blocking

Solution:

Root Cause: Plaintext Caching Blocked by VSM

Windows Credential Guard runs the Local Security Authority (LSA) process inside an Isolated User Mode (IUM) container backed by Virtualization-Based Security (VBS). Because WDigest protocol historically cached unencrypted NTLM password hashes and plaintext credentials directly in LSASS memory, Credential Guard permanently disables WDigest plaintext caching. Applications attempting to query plaintext credentials from LSA receive null responses or access violation errors.

# Diagnostic Verification:

1. Open Event Viewer (eventvwr.msc).
2. Navigate to Applications and Services Logs -> Microsoft -> Windows -> NTLM -> Operational.
3. Look for Event ID 4002 or 4625 in the Security log with sub-status code 0xC000006D (STATUS_LOGON_FAILURE).
4. Confirm WDigest status via PowerShell:

powershell
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name 'UseLogonCredential' -ErrorAction SilentlyContinue

# Step-by-Step Fix:

1. Modernize Application Authentication: Reconfigure the application to use modern Security Support Provider Interface (SSPI) calls such as Kerberos or NTLMv2, which handle authentication tokens without requiring raw password access.
2. Configure Kerberos SSPI: Ensure the application connects via standard AcquireCredentialsHandle() and InitializeSecurityContext() APIs using Negotiate/Kerberos package flags.
3. Deploy Remote Credential Guard (for Admin Tools): If the application operates across network sessions, invoke connections using Remote Credential Guard to pass Kerberos tickets without exposing long-term credentials:

cmd
mstsc.exe /remoteGuard

# Prevention & Long-Term Monitoring:

Enforce WDigest disabling enterprise-wide via Group Policy:

Computer Configuration -> Administrative Templates -> System -> Local Security Authority -> Omit WDigest passwords from memory

(Enabled).

Periodically audit auth attempts using Microsoft's Microsoft Credential Guard Documentation guidelines.

Resolving NTLMv1 and Unconstrained Delegation Blocks

Solution:

Root Cause: Unconstrained Delegation Restricted by Credential Guard

Credential Guard isolates Kerberos ticket-granting tickets (TGT) and NTLM hashes inside VSM. Because Unconstrained Kerberos Delegation allows a destination server to extract a user's raw TGT and re-use it anywhere on the network, Credential Guard blocks TGT delegation to unconstrained targets. Similarly, NTLMv1 authentication requests are blocked due to weak hash protection mechanisms that break VSM boundary isolation.

# Diagnostic Verification:

1. Open Event Viewer and navigate to Windows Logs -> Security.
2. Filter for Event ID 4624 or 4625.
3. Check for Logon Type 3 (Network) with Key Length 0 or Authentication Package listed as NTLM V1 where SubStatus returns 0xC0000388 (STATUS_DOWNGRADE_DETECTED).

# Step-by-Step Fix:

1. Migrate to Constrained Delegation:

Open Active Directory Users and Computers (dsa.msc).

Locate the Service Account running the application.

Open Properties -> Delegation tab.

Change from *Trust this user for delegation to any service (unconstrained)* to Trust this user for delegation to specified services only (constrained).

Select Use Kerberos only or Use any authentication protocol (for protocol transition).

2. Configure Resource-Based Constrained Delegation (RBCD): If crossing domain boundaries, run PowerShell on the target computer account:

powershell
$FrontEndApp = Get-ADServiceAccount -Identity 'AppServiceAcct'
Set-ADComputer -Identity 'TargetServer' -PrincipalsAllowedToDelegateToAccount $FrontEndApp

3. Disable NTLMv1 Fallback: Upgrade application connection strings to explicitly enforce NTLMv2 or Kerberos to prevent protocol downgrade attempts.

# Prevention & Long-Term Monitoring:

Audit Unconstrained Delegation accounts in AD using PowerShell:

powershell
Get-ADObject -Filter {UserAccountControl -band 0x80000} -Properties UserAccountControl, ServicePrincipalNames

Transition all service delegations to RBCD.

Fixing Kerberos DES/RC4 Encryption Suite Restrictions

Solution:

Root Cause: Weak Encryption Types Disabled in VSM

When Credential Guard is operational, the Virtual Secure Mode (VSM) Kerberos package disables weak cryptographic suites, specifically DES (Data Encryption Standard) and RC4-HMAC. If an application or domain user account only supports RC4 or DES encryption for Kerberos tickets, LSASS cannot derive or decrypt the ticket keys inside the isolated environment.

# Diagnostic Verification:

1. Open Event Viewer -> System Log.
2. Filter for Source Kerberos-Key-Distribution-Center (Event ID 14 or Event ID 16).
3. Check the message text for: The digital signature of the object could not be verified because weak encryption types (DES/RC4) are disabled or ticket encryption type listed as 0x1 (DES-CBC-CRC) / 0x17 (RC4-HMAC).

# Step-by-Step Fix:

1. Enable AES Encryption on Application Service Accounts:

powershell
Set-ADUser -Identity 'AppServiceAccount' -KerberosEncryptionType AES128,AES256
Set-ADServiceAccount -Identity 'AppgMSA' -KerberosEncryptionType AES128,AES256

2. Update Domain Controller Group Policy:

Open gpmc.msc and navigate to

Default Domain Controller Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options

Double-click Network security: Configure encryption types allowed for Kerberos.

Ensure AES128_HMAC_SHA1, AES256_HMAC_SHA1, and Future encryption types are checked.

3. Purge Ticket Cache on Client:

cmd
klist purge

# Prevention & Long-Term Monitoring:

Run an AD audit to flag accounts restricted to legacy RC4/DES encryption:

powershell
Get-ADUser -Filter {msDS-SupportedEncryptionTypes -band 0x3} -Properties msDS-SupportedEncryptionTypes

Resolving Remote Desktop & Administrative Delegation Failures

Solution:

Root Cause: Credential Guard Restricts Outbound Credential Passing

Credential Guard prevents standard Network Level Authentication (NLA) from passing raw administrative credentials over Remote Desktop Protocol (RDP) sessions or PowerShell Remoting (WinRM). If the destination server does not support Remote Credential Guard or restricted admin mode, the connection fails during handshaking.

# Diagnostic Verification:

1. Attempt RDP connection via command line:

cmd
mstsc.exe /v:TargetServer

2. Observe error dialog: The remote computer requires Network Level Authentication... or CredSSP encryption oracle remediation failure.
3. Check Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-ClientActiveXCore -> Operational for Event ID 1026.

# Step-by-Step Fix:

1. Connect Using Remote Credential Guard: Execute MSTSC with the /remoteGuard flag, which redirects Kerberos authentication requests back to the client LSASS rather than sending password hashes:

cmd
mstsc.exe /v:TargetServer.domain.com /remoteGuard

2. Configure Host Policy for Restricted Admin Mode:

On the target remote server, open PowerShell as Administrator.

Enable Restricted Admin mode in the registry:

powershell
New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name 'DisableRestrictedAdmin' -Value 0 -PropertyType DWORD -Force

3. Enable Credential Delegation via GPO:

Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

Enable Restrict delegation of credentials to remote servers and set mode to Require Remote Credential Guard.

# Prevention & Long-Term Monitoring:

Deploy shortcut configurations with /remoteGuard pre-packaged for all enterprise systems administrators.

Which category of SSP, AP, or filter module is failing to load into LSASS?

Unsigned third-party Security Support Provider (SSP) or Authentication Package (AP) DLL
Custom Single Sign-On (SSO) credential provider or password manager plugin
Domain Password Filter DLL (Notification Package) fails validation
Smart Card / PKI Token middleware driver rejected by VSM boundary

Resolving Unsigned SSP / AP Loading Violations in LSA PPL

Solution:

Root Cause: LSA Protected Process Light (PPL) Code Integrity Block

When Credential Guard is enabled, Windows automatically enforces LSA Protection (Protected Process Light / PPL). Under LSA PPL, lsass.exe will only load DLL modules that are digitally signed with a valid Microsoft WHQL or Microsoft Software Verification Root certificate. Any third-party Security Support Provider (SSP) or Authentication Package (AP) lacking an ELAM/PPL-compatible signature is blocked at kernel load time.

# Diagnostic Verification:

1. Open Event Viewer (eventvwr.msc).
2. Navigate to Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.
3. Search for Event ID 3033 or 3004.
4. Note the file path of the blocked module (e.g., C:\Windows\System32\customssp.dll) and verify error message: *Code Integrity determined that a process (\Device\HarddiskVolume2\Windows\System32\lsass.exe) attempted to load a image that did not meet the Microsoft signing level requirements*.

# Step-by-Step Fix:

1. Identify and Audit the Registered Module: Inspect LSA security packages in the Windows Registry:

powershell
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Security Packages'

2. Update Module to WHQL/PPL Signed Version: Contact the software vendor to obtain an updated binary signed with a Microsoft PPL-compatible certificate.
3. Enable LSA Audit Mode (Temporary Troubleshooting): Test whether PPL signature enforcement is the sole root cause by setting LSA Protection to Audit Mode:

powershell
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'AuditLevel' -Value 8 -Type DWord

*Reboot the machine. If the application works, the binary signature is confirmed as the blocker.*
4. Remove Unsigned Package (If Obsolete): Edit the Security Packages multi-string key in HKLM\SYSTEM\CurrentControlSet\Control\Lsa and remove the unsigned DLL name.

# Prevention & Long-Term Monitoring:

Verify all custom authentication binaries prior to deployment using PowerShell:

powershell
Get-AuthenticodeSignature -FilePath 'C:\Windows\System32\vendor_ssp.dll'

Fixing Custom SSO & Credential Manager Hooking Failures

Solution:

Root Cause: Injected API Hooks Blocked by VSM Boundary

Legacy Single Sign-On (SSO) clients and enterprise password extensions often attempt to hook internal LSA functions (such as LsaLogonUser or SpAcceptLsaModeCredential) via process injection or custom DLL injection. Because Credential Guard moves sensitive credential handles to Virtual Secure Mode (VSM), direct memory access and unauthenticated API hooks are rejected with STATUS_ACCESS_DENIED (0xC0000022).

# Diagnostic Verification:

1. Check application startup logs for initialization failure codes 0x80070005 or 0xC0000022.
2. Open Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Security-Mitigations -> Operational.
3. Search for Event ID 12 indicating blocked process injection or unauthorized memory modification targeting lsass.exe.

# Step-by-Step Fix:

1. Migrate to Standard Winlogon Credential Provider Architecture: Replace legacy memory-hooking plugins with standard Windows Credential Provider interfaces (ICredentialProviderCredential2).
2. Remove Injected Hook DLLs from AppInit_DLLs:

powershell
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows' -Name 'LoadAppInit_DLLs' -Value 0 -Type DWord

3. Reconfigure SSO via Web/SAML or Entra ID Join: Transition local enterprise SSO integrations to use modern OAuth2 / SAML / WebAuthn tokens rather than capturing desktop LSA credentials.

# Prevention & Long-Term Monitoring:

Audit registry autoruns for unauthorized LSA injects under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Authentication\Credential Providers.

Resolving Domain Password Filter (Notification Package) Loading Blocks

Solution:

Root Cause: Unverified Notification Package Registration

Password filter DLLs registered under Notification Packages execute inside lsass.exe every time a user changes their password. With Credential Guard / LSA PPL enabled, any password filter lacking a Microsoft code integrity signature will fail to load, disabling password policy enforcement or preventing users from completing password resets.

# Diagnostic Verification:

1. Open Event Viewer -> System Log.
2. Look for Event ID 306 or 309 from source LSASRV: *The Local Security Authority failed to load the notification package <DLL_Name>*. Error code: 0xC0000428 (STATUS_INVALID_IMAGE_HASH).

# Step-by-Step Fix:

1. Check Filter Registration: Inspect registered notification packages:

powershell
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Notification Packages'

2. Verify Driver/DLL Authenticode Signature:

powershell
Get-AuthenticodeSignature -FilePath 'C:\Windows\System32\custom_pwd_filter.dll'

3. Apply Vendor Update or Catalog File: Obtain a WHQL-signed update from the software vendor. If using an internally developed DLL, submit the binary to Microsoft via the Hardware Dev Center portal for PPL catalog signing.
4. Safely Unregister Failing Filter: If emergency recovery is required, remove the entry from Notification Packages multi-string value in HKLM\SYSTEM\CurrentControlSet\Control\Lsa and reboot the domain controller or workstation.

# Prevention & Long-Term Monitoring:

Test all DC password filter updates in an isolated OU using LSA Audit Mode (AuditLevel = 8) before broad deployment.

Fixing Smart Card & PKI Token Driver Failures in Credential Guard

Solution:

Root Cause: Legacy PKI Middleware Operating Outside CNG Provider Model

Legacy Smart Card and HSM drivers using custom CryptoAPI (CAPI) Authentication Packages often attempt direct hardware I/O or unprotected shared memory access with LSASS. Credential Guard requires Smart Card authentication to interface through Microsoft Cryptography Next Generation (CNG) Key Storage Providers (KSP) or PPL-compliant Key Distribution Center (KDC) proxy modules.

# Diagnostic Verification:

1. Insert PKI token/smart card and observe error: *A device attached to the system is not functioning* or *The requested Key Storage Provider is not supported*.
2. Open Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Smartcard-Trigger -> Operational.
3. Look for Event ID 100 or Event ID 611 in the Security log (STATUS_PKINIT_FAILURE).

# Step-by-Step Fix:

1. Replace Legacy CAPI Drivers with CNG KSP Drivers: Uninstall legacy PKI middleware and install modern CNG-compliant Smart Card drivers provided by the vendor.
2. Verify Registered KSP Providers: Check available providers via PowerShell:

powershell
Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\Cryptography\Defaults\Provider'

3. Switch to Windows Class Driver: Configure Windows to use the native Microsoft Base Smart Card Crypto Provider by removing vendor-specific filter drivers from HKLM\SYSTEM\CurrentControlSet\Control\Class\{50DD1858-CD8A-11D1-AC75-00C04FB98820}.

# Prevention & Long-Term Monitoring:

Ensure all PKI tokens deployed across the organization comply with Microsoft's Minidriver Specification v7 or higher.

Which application or system tool is encountering access denial or handle opening failures against LSASS?

Antivirus, EDR agent, or security monitoring sensor blocked from inspecting lsass.exe process
Diagnostic or crash-dump tool failing to generate minidumps of LSA process memory
Privileged Access Management (PAM) or Local Admin Password (LAPS) agent failure
User script or automated deployment task failing on OpenProcessToken access handle

Resolving EDR and Antivirus STATUS_ACCESS_DENIED (0xC0000022) Errors

Solution:

Root Cause: VSM Memory Isolation Blocking Kernel Handles

Credential Guard isolates lsass.exe memory inside a virtualized enclave managed by the Hyper-V hypervisor. Even processes running with NT AUTHORITY\SYSTEM or kernel-level drivers cannot open process handles with PROCESS_VM_READ, PROCESS_VM_WRITE, or PROCESS_ALL_ACCESS rights against LSASS. Security agents attempting to hook LSASS memory receive STATUS_ACCESS_DENIED (0xC0000022).

# Diagnostic Verification:

1. Inspect EDR/AV console or agent debug log (agent.log).
2. Search for entry: Failed to open process handle for PID <lsass_pid> with Error 0x5 (ERROR_ACCESS_DENIED) or 0xC0000022 (STATUS_ACCESS_DENIED).
3. Verify Sysmon log (Event ID 10: ProcessAccess) showing targeted access mask 0x1410 or 0x1F0FFF targeting lsass.exe being stripped to 0x1000 (PROCESS_QUERY_LIMITED_INFORMATION).

# Step-by-Step Fix:

1. Update EDR Agent to VBS-Aware Release: Contact your EDR vendor (CrowdStrike, Defender for Endpoint, SentinelOne, Carbon Black) to verify the sensor version supports Windows Credential Guard.
2. Configure EDR to Use Microsoft Event Tracing (ETW): Modern EDRs monitor LSASS behavior via Microsoft-Windows-Threat-Intelligence ETW provider rather than direct memory injection.
3. Verify Kernel Driver Registration: Ensure the security driver registers process creation and handle callbacks via Microsoft-sanctioned ObRegisterCallbacks with stripped access rights:

powershell
# Verify driver status in PowerShell
Get-Service -Name 'EDRDriverName' | Select-Object -Property Name, Status, StartType

# Prevention & Long-Term Monitoring:

Never grant AV/EDR drivers full handle access to LSASS; rely exclusively on ETW Threat Intelligence feeds.

Resolving Diagnostic & Crash Dump Failures Against LSASS

Solution:

Root Cause: MiniDumpWriteDump Restrictive Enclave Controls

Diagnostic utilities (such as ProcDump, WinDbg, or custom crash report generators) call Win32 APIs like MiniDumpWriteDump() or ReadProcessMemory() to generate memory dumps of lsass.exe. Under Credential Guard, LSASS memory pages residing in Isolated User Mode (IUM) are encrypted and inaccessible to user-mode calls, causing dump generation to fail instantly.

# Diagnostic Verification:

1. Execute ProcDump against LSASS in elevated Command Prompt:

cmd
procdump.exe -ma lsass.exe C:\dumps\lsass.dmp

2. Observe error output: Error writing dump file: The handle is invalid (0x00000006) or Access is denied (0x00000005).

# Step-by-Step Fix:

1. Use LiveKD for Hypervisor-Level Kernel Debugging: To inspect system state without breaking VSM boundaries, use LiveKD from Sysinternals:

cmd
livekd.exe -ml

2. Enable LSA Logging via Event Tracing for Windows (ETW): Capture LSA diagnostic traces instead of memory dumps:

powershell
logman start LsaTrace -p 'Microsoft-Windows-LSA' 0xffffff -o C:\Logs\LsaTrace.etl -ets
# Reproduce the issue, then stop trace
logman stop LsaTrace -ets

3. Analyze ETL Trace in Windows Performance Analyzer (WPA): Open LsaTrace.etl in WPA to inspect authentication failure stack traces without reading raw process memory.

# Prevention & Long-Term Monitoring:

Remove automated scripts attempting raw memory dumps of lsass.exe from monitoring workflows.

Fixing PAM Agent and Local Admin Password Manager (LAPS) Failures

Solution:

Root Cause: Password Interception Hook Violation

Legacy Privileged Access Management (PAM) agents attempt to intercept password update events by dynamically modifying LSASS function pointers in RAM. Credential Guard and Hypervisor-Protected Code Integrity (HVCI) render LSA memory read-only to external threads, causing PAM agent memory writes to trigger a Kernel Security Check Failure (BSOD 0x00000139) or process crash.

# Diagnostic Verification:

1. Check Application Log in Event Viewer for crash events from source Application Error (Event ID 1000).
2. Verify faulting module name is a PAM agent DLL (e.g., pam_hook.dll) targeting lsass.exe.

# Step-by-Step Fix:

1. Migrate to Windows LAPS (Native): Replace legacy third-party local admin management tools with native Windows LAPS integrated into Active Directory or Microsoft Entra ID.
2. Configure Native LAPS via Schema Upgrade:

powershell
# Update AD Schema for Windows LAPS
Update-LapsADSchema
Set-LapsAADPasswordReplicationPolicy -Identity 'OU=Workstations,DC=domain,DC=com' -AllowedPrincipals 'Domain Admins'

3. Update PAM Integration: Ensure the PAM vendor uses official Windows LSA Password Filter interfaces or RPC/WMI query mechanisms rather than DLL memory injection.

# Prevention & Long-Term Monitoring:

Standardize local password management on native Windows LAPS (LapsCS.dll).

Resolving Script and Automation Token Manipulation Failures

Solution:

Root Cause: Restricted Token Duplication Across VSM Sessions

PowerShell scripts, scheduled tasks, or automated deployment tools (such as Ansible or SCCM task sequences) often attempt token duplication using OpenProcessToken() and DuplicateTokenEx() from lsass.exe or winlogon.exe handles. Credential Guard restricts token handle inheritance across isolated sessions.

# Diagnostic Verification:

1. Run automation script manually in elevated PowerShell session.
2. Observe native Win32 error: Exception calling OpenProcessToken: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

# Step-by-Step Fix:

1. Refactor Script to Avoid Token Impersonation: Replace API-level token duplication with standard Start-Process -Credential or native PowerShell Remoting (Invoke-Command).
2. Run Scheduled Tasks Under SYSTEM or Dedicated Service Account: Reconfigure the automation task in Task Scheduler (taskschd.msc) to run under NT AUTHORITY\SYSTEM with *Run with highest privileges* enabled, eliminating the need to duplicate user logon tokens.
3. Utilize Group Managed Service Accounts (gMSA): Replace hardcoded credential tokens in scripts with gMSA accounts:

powershell
New-ADServiceAccount -Name 'TaskServiceGMSA' -DNSHostName 'task.domain.com' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Computers'

# Prevention & Long-Term Monitoring:

Audit environment scripts for calls to advapi32.dll token duplication functions.

Which hypervisor, system driver, or policy conflict is causing system crashes or operational failure?

Third-party hypervisor (VMware Workstation, VirtualBox) fails to run alongside Credential Guard
Selective enterprise requirement to disable Credential Guard for specific legacy workstation groups
System fails to clear UEFI persistent variables after disabling Credential Guard policy
Incompatible system or security driver causing BSOD (Hypervisor-Protected Code Integrity crash)

Resolving Third-Party Hypervisor Coexistence Conflicts (VMware / VirtualBox)

Solution:

Root Cause: Exclusive VT-x/AMD-V Hardware Locking

Credential Guard relies on the Windows Hypervisor platform (Hyper-V) running beneath the operating system. Legacy versions of third-party hypervisors (such as VMware Workstation prior to v15.5 or VirtualBox prior to v6.1) attempt to access Intel VT-x or AMD-V CPU virtualization extensions directly, colliding with Hyper-V's root partition lock.

# Diagnostic Verification:

1. Launch virtual machine in VMware Workstation or VirtualBox.
2. Observe error pop-up: *VMware Workstation and Device/Credential Guard are not compatible* or *Cannot enable nested VT-x/AMD-V*.

# Step-by-Step Fix:

1. Enable Windows Hypervisor Platform (WHPX):

Open PowerShell as Administrator.

Install WHPX feature to allow third-party hypervisors to run on top of Hyper-V:

powershell
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All

2. Upgrade Hypervisor Application:

Upgrade VMware Workstation to version 16.2 or higher.

Upgrade VirtualBox to version 7.0 or higher.

3. Configure VMware to Use WHPX Execution Engine:

Open VMware Workstation -> Edit -> Preferences -> Memory/Engine.

Enable support for *Windows Hypervisor Platform*.

# Prevention & Long-Term Monitoring:

Ensure all workstation developer images ship with modern hypervisor builds compatible with WHPX API.

Disabling Credential Guard via Group Policy for Legacy Systems

Solution:

Root Cause: Enterprise System Incompatibility Exemption

When a critical legacy line-of-business application cannot be updated to support modern SSPI/Kerberos protocols or PPL code signing, Credential Guard must be disabled selectively via Group Policy for specific Organizational Units (OUs).

# Diagnostic Verification:

1. Verify Credential Guard state using PowerShell:

powershell
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

*Value 1 indicates Credential Guard is active.*

# Step-by-Step Fix:

1. Open Group Policy Management Editor (gpmc.msc).
2. Navigate to: Computer Configuration -> Administrative Templates -> System -> Device Guard (or Virtualization Based Security).
3. Double-click Turn On Virtualization Based Security.
4. Set policy to Enabled.
5. Under Credential Guard Configuration, set dropdown to Disabled.
6. Link GPO specifically to the Target Legacy OU.
7. Force policy update on client workstation:

cmd
gpupdate /force

8. Reboot target workstation.

# Prevention & Long-Term Monitoring:

Maintain an isolated OU for Credential Guard exemptions and conduct quarterly reviews to re-evaluate vendor software compliance.

Clearing Persistent UEFI Firmware Variables for Complete Removal

Solution:

Root Cause: Persistent EFI Boot Variables

When Credential Guard is turned on, Windows writes secure persistent state flags directly to the system's UEFI firmware (EFI variables). Disabling Credential Guard in Group Policy or Registry alone does not clear these firmware flags, causing Virtualization-Based Security to remain active across system reboots.

# Diagnostic Verification:

1. Open PowerShell as Administrator.
2. Run:

powershell
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesRunning

3. If output shows 1 despite GPO being set to Disabled, persistent EFI variables are locking the VSM state.

# Step-by-Step Fix:

1. Clear Registry LSA Configuration Flags:

cmd
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

2. Delete UEFI Firmware Boot Variables Using BCDEDIT:

cmd
bcdedit /set {0cb3b571-2f2e-430b-a561-55a4b0038574} vsmlaunchtype Off

3. Shut Down Machine and Clear Hardware State: Shut down workstation, power on, and enter UEFI/BIOS setup.
4. Accept Physical Presence Prompt: During boot, press F12 or Win Key (as prompted by system firmware) to confirm clearing of Microsoft Credential Guard EFI variables.

# Prevention & Long-Term Monitoring:

Use enterprise deployment scripts containing bcdedit clearing routines when decommissioning Credential Guard across hardware fleets.

Fixing Incompatible Security Drivers and HVCI Kernel Crashes

Solution:

Root Cause: Hypervisor-Protected Code Integrity (HVCI) Driver Collisions

Credential Guard operates alongside Hypervisor-Protected Code Integrity (HVCI). HVCI uses hardware virtualization to verify that all kernel-mode drivers running in memory are securely signed and free from unsafe memory allocations. Older drivers (e.g., legacy storage controllers, anti-cheat software, custom VPN drivers) violate HVCI memory management rules, causing system BSODs (PAGE_FAULT_IN_NONPAGED_AREA or DRIVER_VERIFIER_DETECTED_VIOLATION).

# Diagnostic Verification:

1. Open Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.
2. Locate Event ID 3004 or Event ID 3082.
3. Note the driver filename listed in the log (e.g., incompatible_driver.sys).
4. Verify code integrity enforcement status via PowerShell:

powershell
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object HypervisorEnforcedCodeIntegrityStatus

# Step-by-Step Fix:

1. Update or Replace Non-Compliant Driver:

Search vendor support portal for WHQL HVCI-compliant driver packages.

2. Disable HVCI via Registry (If Driver Update Unavailable): If an urgent driver update is not available, temporarily disable Hypervisor-Enforced Code Integrity while leaving Credential Guard active:

powershell
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity' -Name 'Enabled' -Value 0 -Type DWord

3. Reboot the system.

# Prevention & Long-Term Monitoring:

Run the official Microsoft Driver Verifier utility (verifier.exe) with code integrity checks enabled on standard staging hardware before approving driver updates across enterprise networks.

Related Diagnostic Guides

USB Drive Shows Shortcut Virus: Remove Without Format

Browser Extensions Stealing Data: Audit and Remove

Google Account Suspicious Activity: Device Check

Microsoft Account Hacked: Lockdown and Recovery Steps

Notion Offline Mode Data Lost: Version History & Cache Recovery Guide

Subscribe to StepDiag

Embed Guide on Your Website