A security support provider (SSP) on a Microsoft Windows computer does not function as expected, and the following event is logged in the System log:
Event Type: Error
Event Source: LsaSrv
Event Category: Devices
Event ID: 5000
The security package <SSP Name> generated an exception. The package is now disabled. The exception information is the data.
0000: c0000005 00000000 00000000 78566df3
... There may also be scenarios in which the Lsass.exe process crashes, but there is no memory dump file in the system.
In this event, <SSP Name> represents the name of the SSP that encountered the problem.
The list of SSPs that may encounter this problem includes but is not limited to the following:
This event is logged if an SSP encounters an exception. 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. Or, the exception is caught and dismissed by a component in LSASS.
When this problem occurs, LSASS stops using the affected SSP. To recover the computer, restart it. However, the exception may occur again.
For information about how to collect a memory dump of the problem, see the "More information" section. For assistance for the data gathering process and problem analysis, contact Microsoft Support (as governed by your support contract).
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
The Local Security Authentication Subsystem (LSASS) process protects itself from software problems in authentication packages. It catches the exception of the security provider and then disables the package. Whether the LSASS process ends and WER can write a dump file 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 not cleaned up in its execution context, the integrity of the LSASS process cannot be guaranteed. The affected execution context may include orphaned critical sections. This might later cause worker threads in LSASS to deadlock. When this occurs, the operations of the computer appear to be impaired. This is in addition to the problems that are caused by disabling the SSP.
Therefore, we recommend 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.
Configure WER to keep 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" -ForceNew-Item -Path "c:\procdumps" -ForceSet-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.
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:
- Get the Procdump download, and expand it on the server that you want to investigate:
- 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
- The command line limits the number of dump files to 20. You might want to adjust the number of files and your cleanup of unnecessary dump files that have other exceptions, depending on your scenario.
The next time that an exception occurs, User ProcDump writes a memory dump file to the location that you specified. The dump file in which the "last modified" time stamp is closest to the time stamp of Event ID 5000 should be the one that is useful for analysis. You can pass the process dump file to Microsoft or to the vendor of the authentication package for analysis.