Subject: Bitdefender interfering with Windows 11 (23H2) feature update installation
Environment:
- Windows 11, version 23H2, build 22631.7582 (upgrading to 24H2/25H2)
- Bitdefender [product name/version here]
OK; disclaimer: I must have been sleeping in class, not noticing that the major updates were not being installed over so long time - but I did make sure that the update processes were running; assuming that would be enough.
Issue 1 — Parallel Windows Update sessions from Bitdefender's own patch-scan feature:
WindowsUpdate.log shows Bitdefender's Vulnerability > Windows Updates check (ClientId = "Bitdefender Scan Service") independently calling the Windows Update Agent COM API to run its own search/download sessions, in parallel with the OS's native update orchestration. One such Bitdefender-initiated download call failed with error 8024001E (WU_E_SERVICE_STOP), coinciding with the Windows Update service being torn down/restarted mid-session. The OS's own feature-update download orchestrator (wuuhosdeployment.dll) also showed a 5+ minute stall followed by error 80070652 (ERROR_INSTALL_ALREADY_RUNNING), consistent with session contention between two concurrent WUA clients.
Issue 2 — Certificate chain validation failures traced to Encrypted Web Scan (TLS interception):
Two specific feature-update packages repeatedly failed CertVerifyCertificateChainPolicy with error 800B0109 (CERT_E_UNTRUSTEDROOT) across multiple separate days/attempts, despite the log confirming the files were genuinely Microsoft-signed. certutil -verifystore Root confirmed "Bitdefender Personal CA.Net-Defender" is installed as a trusted root, i.e. Bitdefender's Encrypted Web Scan performs TLS interception on all HTTPS traffic, including Windows Update / Delivery Optimization downloads (observed host: tlu.dl.delivery.mp.microsoft.com). These downloads are transferred in hundreds of chunked subranges; interception/reassembly of this kind of segmented large-file transfer appears to intermittently corrupt the payload, producing a file whose embedded signature no longer validates its chain even though it's genuinely Microsoft's.
Workaround applied:
Added exceptions under Online Threat Prevention for *.windowsupdate.com, *.update.microsoft.com, *.delivery.mp.microsoft.com, *.dl.delivery.mp.microsoft.com, and tlu.dl.delivery.mp.microsoft.com. This (hopefully) will help resolve the certificate validation failures.
Request:
Could Bitdefender consider:
(a) excluding Microsoft's Windows Update/Delivery Optimization domains from Encrypted Web Scan by default, and
(b) reviewing whether the Vulnerability > Windows Updates feature's own WUA API calls should be more carefully sequenced against OS-initiated update sessions to avoid the contention shown above?
(Happy to share the full WindowsUpdate.log and certutil output, if of any help to you).
