nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Black screen after Windows logon – possible conflict between WithSecure EDR, Microsoft Defender and latest Windows updates

ISICONCEPT

Hello,
We are currently experiencing a serious issue on several Windows workstations since the latest WithSecure EDR update combined with recent Windows Updates.
It looks like a potential conflict between WithSecure EDR / Microsoft Defender and the latest Windows build.
Issue description
After unlocking or logging into a Windows session, the user is faced with:

A black screen
No taskbar
No Start menu
Applications do not respond
Keyboard shortcuts (Ctrl+Alt+Del, Win+X, etc.) are ineffective
The system is not usable at all

The session seems to load partially, but Explorer never initializes.
Temporary workaround
The only workaround we have found so far is the following:

Disable antivirus protection in the WithSecure profile / policy
Immediately after disabling protection, the desktop, taskbar and applications load normally
Re-enabling protection brings the issue back on the next logon/unlock

This strongly suggests an AV/EDR-related conflict at session startup.
Environment (overview)

OS: Windows 10 / Windows 11 (fully up to date)
WithSecure products: WithSecure EDR (antivirus + EDR enabled)
Microsoft Defender: present (standard Windows Defender coexistence)
Domain environment (AD-joined machines)
Issue occurs after recent Windows + WithSecure updates

Additional observations

The issue happens only when antivirus protection is enabled
No obvious blocking popup or alert is shown
No usable error message on screen, only a black session
Happens at logon or unlock, not necessarily after boot

Questions

Has anyone else experienced a black screen / broken user session after recent WithSecure and Windows updates?
Is there a known incompatibility between WithSecure EDR and Microsoft Defender in recent builds?
Are there any recommended exclusions, hotfixes, or configuration changes to avoid this behavior?
Any specific logs (fsdiag, WithSecure logs, Windows event IDs) we should focus on?

Any feedback or similar experiences would be greatly appreciated, as this issue has a major impact on users.
Thank you in advance.
Best regards,

Find more posts tagged with

Accepted answers

Riptide

For anyone coming to this fresh: we've narrowed the issue down to Application Control. Disabling it appears to resolve the black screen on sign-in for affected users.

All comments

ISICONCEPT

We would like to provide an update on this issue.

After further investigation on our side, we have identified the root cause, and it was related to a misconfiguration in our DeepGuard settings.

We had configured a blocking rule for a specific application, and it appears that this rule was causing the issue during user session startup, leading to the black screen and unresponsive desktop.

After correcting this configuration, the problem is now resolved on the affected workstations.

So in our case, this was not a global incompatibility but rather a DeepGuard policy configuration issue that impacted the Windows session initialization.

Thank you for your guidance, which helped us narrow down the problem.

Best regards,
Matthieu

Riptide

For anyone coming to this fresh: we've narrowed the issue down to Application Control. Disabling it appears to resolve the black screen on sign-in for affected users.

Riptide

@ISICONCEPT

Have you had any success figuring this out yet?

Riptide

We are also experiencing this same issue, and it is resolved by doing as ISICONCEPT has. Sadly, this is also affecting our Azure Virtual Desktops. The Azure Virtual Desktops also show behavior where certain apps won't launch (Teams, Outlook, etc.) but after disabling all of WithSecure's security features, the apps will open as expected. The black screens on login are the most plaguing item though.

ISICONCEPT

Hello,

We followed your recommendations, but unfortunately the issue is still occurring on our side.

To unblock the situation and restore user access, we applied a workaround by disabling several settings in the "Integrations" section of the profile (see attached screenshot):

EDR sensor (Activer le capteur EDR) → disabled
Advanced remediation (Remédiation avancée) → disabled
WMI provider (Fournisseur WMI) → disabled
BitLocker key collection (Collecter les clés de récupération BitLocker) → disabled

Since applying these changes, the issue seems partially mitigated, and affected workstations can log in normally again.

However, the problem still occurs occasionally, although less frequently based on our observations.
It also appears that the issue only affects Windows 11 machines running WithSecure version 26.2, based on what we have identified so far.

Could you please confirm:

if this behavior is a known issue,
which specific component is causing the problem (EDR sensor, remediation, etc.),
and if a fix or recommended configuration is available?

We are currently seeing this across multiple endpoints, so any clarification or permanent solution would be greatly appreciated.

Thank you for your support.

Best regards,
Matthieu

Sethu Laks

Hi @ISICONCEPT

Thanks for reaching out the WithSecure community!

What you're describing (black screen after login, missing taskbar, everything frozen until you disable WithSecure) really does sound like a conflict between WithSecure and Windows during startup, rather than Windows itself being broken.

It's likely one specific protection features in WithSecure that's causing the hang, not the whole thing. Good news is we can probably narrow it down without leaving your antivirus completely disabled.

Quick thing to check first:

Can you verify whether Microsoft Defender is still actively scanning in the background? Sometimes when you enable WithSecure agent, Defender goes into "passive mode," but occasionally both run at the same time. If they're both actively scanning during login, that could be creating a bottleneck. (You don't need to change anything yet, just checking!)

Here's the best way to pinpoint the culprit:

Instead of disabling all of WithSecure agent components, try turning off one protection feature at a time in your policy:

First, try disabling real-time scanning and log out/back in
If that doesn't fix it, re-enable real-time scanning and try disabling behavioral/application control/browsing protection, deepguard features.

Whichever one makes the problem disappear is likely the troublemaker. That way you'll know exactly which feature to keep disabled (as a temporary workaround) until this gets fixed properly.

If you want to dig deeper:

Please turn on debug mode, wait for the black screen to appear, and then collect the wsdiag immediately after the freeze. Once you have logs, we recommend submitting a support case and including the debug wsdiag file, this will help determine whether the issue is caused by a recent Windows update or something specific to your system configuration.

In the meantime:

Once you find which protection feature causes the issue, create a temporary policy that disables just that one feature. That way your antivirus keeps working for everything else, you're just turning off the problematic module until it's fixed.

Hope this helps! Let us know which protection feature ends up being the culprit, that'll help us (and other users) figure out if there's a pattern here.

Best regards,
Sethu
Community Moderator | Technical Support Engineer

WithSecure Asiakastuki – Vianmääritys, Ohjeet ja Lataukset | WithSecure™