The LSAISO (LSA Isolated) process experiences high CPU usage on a computer that is running Windows 10, Windows Server 2016 or later versions.
In Windows, the LSAISO process runs as an Isolated User Mode (IUM) process in a new security environment that is known as Virtual Secure Mode (VSM).
Applications and drivers that try to load a DLL into an IUM process, inject a thread, or deliver a user-mode APC may destabilize the entire system. This destabilization can include the high LSAISO CPU scenario that is mentioned in the "Symptoms" section.
To resolve this problem, use one of the following methods.
Method 1: Use the process of elimination
It is common for some applications (such as antivirus programs) to inject DLLs or queue APCs to the LSAISO process. This causes the LSAISO process to experience high CPU usage.
For troubleshooting, it is not possible to attach tools to a IUM process. This prevents you from using the Windows Debugging Tools or WPA\XPERF to capture stack traces during the LSAISO CPU spiking. Therefore, the best troubleshooting method in this scenario is to use the "process of elimination" methodology. To do this, disable applications and drivers until the CPU spike is mitigated. After you determine which software is causing the problem, contact the vendor for a software update. You can reference the ISV recommendations that are listed in the following MSDN topic:
Note This method may require a reboot after you disable the suspected software and drivers as you test for the CPU spike.
Method 2: Check for queued APCs
Download the free Debugging Tools for Windows (WinDbg, KD, CDB, NTSD). These tools are included in both the Windows Driver Kit (WDK) and the Windows Driver Kit (WDK). Then, follow these steps to determine which driver is queuing an APC to LSAISO:
- While you reproduce the CPU spike, generate a kernel memory dump by using a tool such as NotMyFault.exe from the following Sysinternals website:Note A complete memory dump is not recommended because it would require decryption if VSM is enabled on the system. To enable the kernel dump, follow these steps:
- Open the System item in Control Panel, and then select Advanced system settings.
- On the Advanced tab of the System Properties dialog box, select Settings in the Startup and Recovery area.
- In the Startup and Recovery dialog box, select Kernel memory dump in the Write debugging information list.
- Note the Dump File location to use in step 5, and then select OK.
- Open the WinDbg.exe tool from the Debugging Tools for Windows.
- On the File menu, click Symbol File Path, add the following path for the Microsoft Symbol Server to the Symbol path box, and then select OK:
On the File menu, click Open Crash Dump.
Browse to the location of the kernel dump file that you noted in step 1d, and then select Open. Check the date on the .dmp file to make sure that it was newly created during this troubleshooting session.
In the Command window, type !apc, and then press Enter.
The output should resemble the following screen shot.
- Search the results for LsaIso.exe. If a driver that is named "<ProblemDriver>.sys" is listed under LsaIso.exe (as shown in the example screen shot of output in step 6), contact the vendor, and then refer them to the recommended mitigation that is listed in the Isolated User Mode (IUM) Processes topic. Note If no drivers are listed under Lsaiso.exe, this means that the LSAISO process has no queued APCs.
VSM uses isolation modes that are known as Virtual Trust Levels (VTL) to protect IUM processes (also known as trustlets). IUM processes such as LSAISO run in VTL1 while other processes run in VTL0. The memory pages of processes that run in VTL1 are protected from any malicious code that is running in VTL0.
Prior to Windows 10 and Windows Server 2016, the Local Security Authority Subsystem Service (LSASS) process was solely responsible for managing the local system policy, user authentication, and auditing while it also handled sensitive security data such as password hashes and Kerberos keys.
To use the security benefits of VSM, the LSAISO trustlet that runs in VTL1 communicates through an RPC channel with the LSAISO process that is running in VTL0. The LSAISO secrets are encrypted before they are sent to LSASS, and the pages of LSAISO are protected from any malicious code that is running in VTL0.