Intermittent LogonUI.exe - EXCEPTION: Breakpoint during Windows Sign-in

Hi @Wanicha Inburan ,

Thanks for the detailed write-up.

The breakpoint message alone isn't enough to distinguish a defect in a specific provider, an interaction between filters, or an issue in Windows itself.

Multiple Credential Providers can coexist on Windows, so having several installed doesn't by itself establish a conflict. Credential Provider Filters also participate before tile selection, so choosing a different sign-in tile doesn't fully isolate the other components.

Below is what I'd suggest:

1. Check the Application event log

In Event Viewer > Windows Logs > Application, look around the failure time for:

• Application Error (Event ID 1000)
• Windows Error Reporting (Event ID 1001)

Please share the exception code, faulting module name and version, and fault offset. If the faulting module is ntdll.dll or KERNELBASE.dll, the exception stack will still be needed to identify what led to the failure.

2. Enable crash dumps for LogonUI.exe

Run the following from an elevated Command Prompt:

mkdir C:\Dumps

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\LogonUI.exe" /v DumpFolder /t REG_EXPAND_SZ /d C:\Dumps /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\LogonUI.exe" /v DumpType /t REG_DWORD /d 2 /f

After the issue reproduces, check C:\Dumps for a dump file. A full dump can help identify the execution path through the providers and filters.

3. Isolate each product's sign-in components

On a test endpoint with a verified recovery method, test each security/VPN product's sign-in components individually, then together.

Use vendor-supported configuration changes rather than manually deleting Credential Provider or Filter registry entries. Because the issue is intermittent, repeat each scenario several times before drawing a conclusion.

4. Test an approved cumulative update

Build 26100.4202 corresponds to the May 28, 2025 optional preview update, KB5058499. After preserving the initial evidence, testing a current approved cumulative update would also be worthwhile. This is a comparison test, not a confirmed fix for the reported issue.

And please also share security/VPN products and versions are installed and whether the popup appears before selecting a tile, after submitting credentials, or while waiting for MFA/VPN?

Hope these information help. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Hi Percy Nguyen,

Thanks for the advice.

First, we would like to provide some additional observations regarding the issue.

During the affected sign-in flow, we observed an Application Log – Event ID 1000 occurring around the same timeframe as the Windows sign-in issue.

This environment uses Silverfort MFA for Windows Logon. The user first enters the Windows username and password, and then proceeds to an additional Silverfort MFA step, such as OTP verification or MFA enrollment.

We have observed the issue in the following scenarios:

1. OTP / MFA Prompt
   • The user has already entered the username and password successfully.
   • The Silverfort OTP screen is displayed.
   • While the user is waiting to enter the OTP, the popup error appears.
   • The popup interrupts the authentication flow and prevents the user from entering the OTP.
2. MFA Enrollment
   • The user has already passed the username and password stage.
   • The system proceeds to the Silverfort MFA enrollment step.
   • Before the user can complete the enrollment, the popup error appears and the screen becomes unresponsive, preventing any further action.
3. Local Administrator Sign-in
   • The customer confirmed that when signing in with a Local Administrator account that does not require the Silverfort MFA/OTP flow, the Windows sign-in completes normally.
   • The issue has not been observed in this scenario.

Based on the current observations, the issue appears to occur only when the account enters the Silverfort MFA/OTP or enrollment flow after the primary username/password authentication step.

At this stage, we are not concluding that Silverfort is the root cause, but the behavior appears to be associated with the additional MFA flow rather than with the initial Windows username/password authentication itself.