Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

LsaSrv event 5000 disables authentication packages

View products that this article applies to.


An authentication package on a Microsoft Windows computer may not run as expected, and the following event may be logged in the system log:

↑ Back to the top


This event is logged if there's an exception in an authentication package. When the Lsass.exe process crashes, the exception is not caught by the Local Security Authentication Subsystem (LSASS), and Windows Error Reporting (WER) should write the dump file. However, WER may be unable to write a dump file for some reason. Or, the exception is caught and dismissed by a component in LSASS. 

↑ Back to the top


To resolve this problem, restart the computer. However, the exception may occur again. For information about how to collect a memory dump of the problem, see the "More Information" section.  

↑ Back to the top


Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

↑ Back to the top


The Local Security Authentication Subsystem (LSASS) process is designed to protect itself from software problems in authentication packages. It identifies the exception and the security provider and then disables the package. Whether the LSASS process terminates and WER can write a dump depends on the context of the exception and the implementation of the security provider.

Because exceptions are unexpected and the thread that encountered the exception is probably not cleaned up correctly, the integrity of the LSASS process cannot be guaranteed. Therefore, Microsoft recommends that you restart the computer. The exception does not create a memory dump file, and the context of the exception is lost after the event is logged.

To collect memory dump data, use one of the following methods.

Method 1

Configure WER to retain application dump files by setting registry entries. Here's an example for PowerShell in an elevated session:

New-Item -Path "HKLM:\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps" -Force
New-Item -Path "c:\procdumps" -Force
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps" -Name DumpFolder -Value c:\procdumps -Type ExpandString -Force 
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps" -Name DumpType -Value 0x2 -Type dword -Force 

Dump files will now be stored in the C:\procdumps directory.

Method 2
If no dump files are written by WER, download the Process Dump (PROCDUMP) tool, and then configure it to monitor LSASS for access violations (or for any other exception code in the first DWORD value of the event data).

To do this, follow these steps:

  1. Get the Procdump download, and expand it on the server that you want to investigate:
  2. Run the Procdump tool by using the following parameters to catch first chance exceptions and to write the dump files into the C:\lsa-dumps folder:
    Procdump.exe -accepteula -mp lsass.exe c:\lsa-dumps\lsass01.dmp -e 1 -n 20
  3. The command line limits the number of dumps to 20. You might want to adjust the number of dumps and your cleanup of unnecessary dump files with other exceptions, depending on your scenario.

The next time an exception occurs, User ProcDump writes a memory dump file to the location that you specified. You can pass the memory dump file to the vendor of the authentication package for analysis.

↑ Back to the top

Keywords: LsaSrv event 5000

↑ Back to the top

Article Info
Article ID : 828873
Revision : 13
Created on : 5/15/2018
Published on : 5/15/2018
Exists online : False
Views : 2388