Windows 11 KB5074109: Security fixes but notable regressions and KIR guidance

The January 13, 2026 cumulative update for Windows 11 (KB5074109) shipped important security and platform fixes — but early deployments have produced a cluster of regressions that range from intermittent black screens and wallpaper resets to Outlook Classic hangs for POP profiles, Azure Virtual Desktop authentication failures, and a puzzling File Explorer regression that ignores desktop.ini’s LocalizedResourceName entries.

Background / Overview​

KB5074109 advances Windows 11 to OS builds 26100.7623 (24H2) and 26200.7623 (25H2) and bundles a servicing stack update (SSU) with the monthly Latest Cumulative Update (LCU). The update contains a mix of security fixes, an important power-management correction for machines with Neural Processing Units (NPUs), and staged Secure Boot certificate handling intended to avoid large-scale certificate expiry problems. Microsoft published the formal KB and release notes on January 13, 2026. That combination — heavy security content plus platform-level component updates — is the usual recipe for broadly useful fixes but also increases the chance that edge-case configurations will experience regressions. The issues reported since rollout can be grouped into four practical buckets: (1) short black-screen/display freezes and wallpaper resets, (2) Outlook (classic) POP-profile hangs and failure to exit, (3) Azure Virtual Desktop (AVD) and Cloud PC credential prompt/authentication failures, and (4) File Explorer ignoring desktop.ini LocalizedResourceName entries and certain hidden-attribute effects. Community reporting, Microsoft support notes, and independent outlet coverage corroborate these problem classes.

---

What KB5074109 changes (technical summary)​

• New OS builds: 26100.7623 and 26200.7623 (24H2 / 25H2).
• Security baseline and CVE coverage: the January rollup contains many security fixes (the KB and associated Security Update Guide entries list the individual CVEs).
• NPU power-state fix: addresses NPUs remaining powered when the host is idle.
• Secure Boot certificate rollout behavior: KB introduces targeted device eligibility for automatic Secure Boot certificate updates to avoid mass boot failures.
• Packaging: the update is a combined SSU+LCU package; once the SSU portion is applied, it is effectively persistent and complicates naive rollback strategies. DISM sequencing and the Update Catalog are recommended for offline image servicing.

These factual points matter for deployment planning: because the SSU portion is bundled, an uninstall of the combined MSU does not remove the SSU, and administrators should use DISM or the Update Catalog patterns described in the KB and community guides if they plan to manipulate install state.

---

Black screen, display freezes, and wallpaper resets​

Symptoms​

After installing KB5074109 a subset of users report:

• Brief black screens where the desktop freezes for a second or two, then returns.
• Some systems display a plain black desktop wallpaper after the update until the user re-selects their background in Settings → Personalization.
• Reports span systems with both NVIDIA and AMD GPUs, and some affected users link the behavior to DisplayPort link settings (e.g., toggling DisplayPort 1.4 ↔ 1.2 appears to have helped a few users).

Analysis​

These are classic symptoms of a display-driver or shell/Explorer interaction regression that becomes visible when kernel or user-mode components dealing with display pipelines, DPMS state, or display enumeration change. Because KB5074109 updates platform DLLs and potentially triggers driver reinitialization at reboot, short blackouts on resume/initial desktop draw are consistent with a timing or handshake regression between Windows display components and vendor GPU drivers.
Strengths in this situation: the problem is usually transient (desktop recovers without requiring a reboot) and is often resolved by updating GPU drivers or reconfiguring the monitor’s DP mode. Weaknesses: the symptom can be disruptive when it happens during media playback or remote presentations, and in some cases wallpaper/Explorer state resets may annoy users who expect personalization to be persistent. Community reproductions and independent reporting confirm the pattern, but there is not yet a single reproducible hardware fingerprint that identifies all impacted machines.

Recommended mitigations​

• Update GPU drivers to the vendor’s latest release and reboot. If the vendor’s driver is already up to date, try reinstalling or using a clean install option provided by the vendor’s driver installer.
• If black screens correlate with DisplayPort, experiment with toggling DisplayPort mode (1.4 ↔ 1.2) or switching to HDMI on a test machine to verify behavior. Some users reported this temporary workaround helped.
• If wallpaper appears black or reset, reselect the background in Settings → Personalization. This resets the cached wallpaper state and typically restores your chosen image.

If symptoms persist and are operationally impacting, consider rolling back KB5074109 on that machine while retaining an audit trail and risk assessment — but be mindful of the security trade-offs described later.

---

Outlook Classic (POP) hangs and processes that won’t exit​

Symptoms and vendor acknowledgement​

Microsoft has published an advisory acknowledging an emerging issue where classic Outlook profiles that use POP can hang or fail to exit after KB5074109 is installed. Users observe that closing Outlook appears to succeed, but the outlook.exe process remains running; attempts to reopen Outlook then fail or show "Outlook already open" errors. In other cases Outlook becomes unresponsive (Not Responding) and never fully loads. Microsoft has marked the status as Investigating. Community posts show many affected users recovered normal Outlook behavior after uninstalling KB5074109, while Microsoft’s investigation remains ongoing.

Technical considerations​

The issue appears tied to Outlook’s shutdown and profile handling when operating with POP/SMTP account types — a legacy flow that uses local PST stores and synchronous local I/O operations. Changes in Windows platform behavior that affect file locking, shutdown hooks, or COM activation lifetimes can interfere with Outlook’s normal exit path and leave background processes alive.
At the time of writing, Microsoft has not released the line‑by‑line root-cause or the specific module causing the failure; the company’s advisory is limited to symptom description and ongoing investigation. That means any diagnosis about an exact conflicting DLL or subsystem should be treated as provisional until Microsoft issues a fix or technical post-mortem.

Workarounds and mitigation​

• Short-term desktop user workaround:
• Open Task Manager and end the outlook.exe process if Outlook refuses to close. This allows re-opening the client without a reboot, but risks data loss if Outlook was mid-write. Use this only when necessary. Community posts widely recommend avoiding aggressive process kills unless you have no alternative.
• If Outlook remains unusable:
• Uninstall KB5074109 on the affected machine and block reinstallation temporarily. Use caution: removing a security update increases exposure to vulnerabilities patched by that update. Collect logs (Outlook logs, event viewer entries, and Windows Reliability Monitor) and escalate through Microsoft support if in an enterprise.
• Enterprise option:
• For large fleets, escalate through the formal Microsoft support channel and wait for a targeted Outlook update or an out-of-band Windows fix; Microsoft indicated the Outlook and Windows teams are coordinating remediation. Until then, consider instructing users to switch POP accounts to a different client or webmail temporarily if feasible.

---

Azure Virtual Desktop (AVD) and Cloud PC credential failures — Known Issue Rollback (KIR)​

Symptoms and Microsoft confirmation​

Multiple customers saw immediate failures when attempting to connect to Azure Virtual Desktop (AVD) or Windows 365 Cloud PCs after installing KB5074109. The typical symptom is an immediate authentication prompt failure (e.g., “Unable to Authenticate” or an error code such as 0x80080005) that prevents session negotiation before session establishment. Microsoft publicly acknowledged the regression in the KB’s Known Issues section and advised mitigations while engineering develops a fix.

Root cause characterization (what Microsoft said)​

Microsoft’s investigation determined the regression was introduced by a Windows security update that affected client-side credential prompt handling during Remote Desktop/Windows App connections. The vendor described it as a client-side regression (not a cloud-hosted AVD service outage) and recommended KIR and alternate clients as temporary measures.

Known Issue Rollback (KIR) and safe remediation​

Microsoft published a Known Issue Rollback (KIR) that targets only the feature change causing the regression and preserves other security fixes in KB5074109. The KIR is distributed to administrators via Group Policy/MSI and can be applied at scale, which makes it preferable to uninstalling the entire cumulative update (which removes security fixes). The KIR implementation appears to work by toggling a feature-management override in the registry to revert the specific behavior that broke credential prompts. Community-supplied extracts of the KIR policy show the override keys and metadata used.
Practical admin playbook:

• Inventory and scope:
• Identify devices with KB5074109 installed (Settings → System → About or use DISM /online /get-packages to find installed packages).
• Preferred remediation:
• Deploy Microsoft’s KIR via Group Policy / MSI to affected client devices and restart them. KIR reverses only the offending change while keeping the LCU’s security content in place.
• Alternate immediate workaround for end users:
• Use the AVD/Windows App web client (browser) or the classic Remote Desktop client (MSRDC) to connect until KIR or a permanent fix is applied. Microsoft recommended these alternates explicitly.
• Last resort:
• If KIR is not deployable and users cannot connect, consider uninstalling the LCU on critical endpoints — but this should be a carefully scoped emergency action because it removes the security content of KB5074109.

Risk trade-offs​

The KIR mechanism is the operationally prudent choice for enterprises: it avoids the security-versus-availability trade-off of uninstalling the LCU while restoring functionality for remote-desktop dependent workflows. The event also illustrates why AVD/Cloud PC scenarios should be included in update validation suites for enterprise update rings.

---

File Explorer and desktop.ini: LocalizedResourceName no longer respected​

Symptoms and community reports​

Shortly after KB5074109, users reported that File Explorer no longer honors the LocalizedResourceName value inside desktop.ini files. Folder names that previously showed a localized or friendly name now revert to their directory name. Users also reported that marking certain folders hidden no longer removed them from view in the exact ways they expected. Multiple reports on Microsoft Q&A and community forums reproduce the issue and indicate uninstalling KB5074109 restores previous behavior. WindowsLatest independently verified and reported the same behavior in lab tests. The symptom set affects both Known Folders and custom folders that rely on [.ShellClassInfo] / LocalizedResourceName entries.

Analysis and likely causes​

desktop.ini parsing and LocalizedResourceName support are handled by shell components such as explorer.exe, shell32.dll, ExplorerFrame.dll, Windows.FileExplorer.Common.dll, and possibly Windows.Storage.dll. KB5074109 updates some of these components to new versions for the new build, and community troubleshooting suggests the regression is occurring in the shell’s parsing/lookup path rather than being attributable to incorrect file attributes or encoding. Uninstalling the cumulative update appears to revert the behavior immediately, which implies a change in updated shell components is the proximate cause. However, Microsoft has not yet listed this specific behavior as a known issue on the KB page, so vendor acknowledgement is limited to community forums and developer Q&A threads at the time of writing.

Recommended actions​

• If you rely on desktop.ini customizations for workflow or localized folder names, document the required .ini contents and ensure a known-good image snapshot exists before broad deployment.
• Report the problem via Feedback Hub (the recommended escalation path for shell/UI issues) and track Microsoft Q&A threads that mirror your repro steps; multiple customer reports help raise priority.
• For single-user interruption, uninstall KB5074109 to restore previous behavior if the regression is causing unacceptable disruption; but document the security trade-offs and reinstate the update once Microsoft issues a fix.

Be aware that while the community reproductions are robust and consistent, the lack of formal documentation in the KB as a Known Issue means the timeline for an official patch is currently uncertain; treat this as an emerging regression and flag it as a priority if your operations depend on desktop.ini behavior.

---

Deployment guidance and risk assessment for IT teams​

Prioritize validation rings​

Given the mix of security fixes and the observed regressions, follow a conservative staged rollout pattern:

• Pilot ring: test KB5074109 on a representative set of hardware, including GPUs (NVIDIA/AMD), domain-joined devices, AVD/Cloud PC users, and devices that use desktop.ini-based customizations. Track results for at least 7 days.
• Broad pilot: expand to a larger pilot if no regressions are seen. If regressions appear in pilot, hold deployment and apply KIR where relevant or delay rollout.

Prepare rollback and response playbook​

• Keep golden images and snapshots available; because the SSU presence complicates native uninstall, plan reprovisioning or DISM /Remove-Package workflows if you must remove the LCU. Document actions and approval steps.
• If AVD/Cloud PC is mission-critical, prioritize KIR deployment over uninstalling the LCU. Microsoft’s KIR is surgical and preserves most security content.

Communications​

• Communicate to end-users that the update contains significant security fixes but may disrupt specific workflows (POP Outlook users, AVD/CSP users, desktop.ini customizers). Provide alternate connection methods (web client or classic RDP), and give explicit instructions for Task Manager process termination if Outlook hangs and a restart is not feasible.

---

Strengths, weaknesses, and what to expect next​

Strengths​

• Microsoft moved quickly to acknowledge the AVD/Cloud PC regression and published a KIR pathway that avoids wholesale uninstalls of security fixes. That measured mitigation reduces operational risk while preserving the majority of protection afforded by the January update.
• The update plugs substantive security gaps and corrects an NPU power-state bug that could otherwise erode battery life on impacted devices. Those are non-trivial fixes that justify careful deployment rather than wholesale avoidance.

Weaknesses and risks​

• The bundled SSU means rollback is messier than in the past. Imaging and reprovisioning may be safer than relying on wusa /uninstall for combined packages.
• Several regressions affect productivity flows (AVD connections, Outlook POP, desktop.ini customizations). Even if the subset of affected users is small, the operational impact can be large when those users are in customer-facing roles or remote workers that depend on Cloud PCs.
• Some regressions remain unacknowledged in the KB (for example, the desktop.ini LocalizedResourceName issue is widely reported on community forums and Microsoft Q&A but has not been clearly documented in the KB’s Known Issues as of the time of writing). Treat such items as emerging and prioritize feedback submission.

What to expect next​

• Microsoft is actively investigating the Outlook POP issue and has indicated the Windows and Outlook teams are coordinating remediation. A targeted Outlook update or an out-of-band Windows patch is likely; in the meantime, use KIR for AVD/Cloud PC cases and standard driver-update patterns for display issues. Monitor the KB page and Windows Release Health for official updates.

---

Practical checklist — immediate actions for users and admins​

• Confirm build and update status:
• Run winver.exe or check Settings → System → About to verify if the device shows build 26100.7623 or 26200.7623.
• If you rely on AVD/Cloud PC:
• Deploy Microsoft’s KIR via your device-management tooling, or instruct users to use the web client / classic RDP until a fix is available.
• If Outlook Classic POP is unusable:
• End outlook.exe via Task Manager if necessary for immediate recovery; gather logs and consider uninstalling the LCU only if stopping it is essential and other mitigations fail. Escalate to Microsoft support for enterprise cases.
• If you use desktop.ini customizations:
• Test on a non-production machine or retain an image snapshot; file a Feedback Hub report and track Microsoft Q&A threads to raise priority. If you must, uninstall KB5074109 to recover prior behavior, documenting the decision and security trade-offs.
• Update GPU drivers and check monitor settings:
• Use the GPU vendor’s clean-install or latest driver packages; test DisplayPort modes if you see black screens.
• For offline servicing and imaging:
• Use DISM to sequence and install MSU files; to remove just the LCU use DISM /Remove-Package with the exact LCU package name. Avoid wusa /uninstall on the combined package because it won’t remove the SSU piece.

---

Final assessment and recommendation​

KB5074109 contains important security and quality fixes that most organizations will want to deploy. However, the combination of an SSU with a sizeable LCU and visible regressions affecting remote-desktop authentication, classic Outlook POP behavior, desktop.ini parsing, and occasional display blackouts raises a clear and present operational risk for certain user groups.

• Short-term recommendation for enterprises: pause broad rollout until pilot rings have validated behavior for AVD/Cloud PC users and Outlook POP profiles, deploy KIR where AVD is critical, and update GPU drivers across pilot hardware. Maintain documented rollback and reprovisioning procedures for affected images.
• Short-term recommendation for power users and consumers: if you are not using AVD/Cloud PC and do not rely on classic Outlook POP or desktop.ini-driven folder names, install the update to receive security fixes and the NPU power improvement. If you see regression symptoms that impact your workflow, follow the mitigation steps above (driver updates, Task Manager for Outlook, reselect wallpaper) and escalate via Feedback Hub or Microsoft support if necessary.

This episode is a reminder that the monthly cumulative model reduces the window for regressions but also amplifies the consequences of a regression that touches high-impact flows such as authentication and mail-client shutdown logic. Use staged deployment, telemetry-driven gating, and surgical mitigations (KIR) where possible to preserve both security and availability.

---

KB5074109’s security fixes matter — but for a defined subset of users the update also created genuine productivity regressions. Administrators and advanced users should treat this update as a high-priority test case: validate against AVD/Cloud PC and Outlook POP scenarios, stage KIR or other mitigations where needed, and watch Microsoft’s KB and Release Health channels for follow-up patches and engineering notes.

---

Source: Windows Latest Windows 11 KB5074109 issues: black screen, freezes Outlook POP, breaks Azure Virtual Desktop, LocalizedResourceName (desktop.ini)

 

[linuxman74]

To date, no one has ever pointed out that update KB5074109 prevents the use of the Acrobat ActiveX AcroPDF64.dll.
If a piece of software uses this component to display PDFs within its own forms, as of today it no longer works.
If, on the other hand, the 32-bit version of the software is used—which in fact calls AcroPDF.dll (the 32-bit version of the component)—then it works correctly.

 

[ChatGPT]

That’s a very useful catch — and it does look like an emerging regression tied to KB5074109: the 64‑bit Adobe PDF ActiveX control (AcroPDF64.dll) can no longer be hosted/instantiated by some 64‑bit applications after the January 2026 Windows 11 update, while the 32‑bit control (AcroPDF.dll) continues to work in 32‑bit apps. A report consistent with what you’re seeing has already appeared publicly (though it’s not widely covered yet).
Below are practical verification steps, likely cause area, and workarounds you can use right now, plus what I’d need from you to help narrow it down.

---

1) Quick triage: confirm what’s failing​

In the affected 64-bit app, what happens specifically?

• COM creation fails (common): error like 80040154 (Class not registered) or 80004005 / “ActiveX component can’t create object”
• Control instantiates but shows blank/gray
• Host process crashes when the control loads (check Application Event Log / Reliability Monitor)

Also: are you hosting it via WinForms/WPF AxHost, WebBrowser control / MSHTML, MFC, Delphi, etc.? (This matters because some Windows hardening hits MSHTML/ActiveX hosting paths differently.

---

2) Things to try immediately (lowest risk first)​

A) Re-register the 64-bit control (often worth testing)​

If KB5074109 changed registration/permissions behavior or the registration got damaged during update servicing, re-registering can sometimes restore it:

1. Open an elevated Command Prompt
2. Run 64-bit regsvr32 explicitly (important):

%SystemRoot%\System32\regsvr32.exe "C:\Program Files\Adobe\Acrobat Reader*\Reader\AcroPDF64.dll"
(Adjust the path to your actual Adobe install folder.
If registration succeeds but it still won’t instantiate, that’s a strong signal this is not just COM registration.

B) Update Adobe Reader/Acrobat to the newest build available​

If Adobe ships an updated 64-bit ActiveX binary (or changes how it’s hosted), the newest patch may contain a mitigation. (Given the timing, Adobe may not have reacted yet, but it’s still a necessary datapoint.

C) Temporary workaround: run your app as 32-bit (if possible)​

As you noted, forcing the host to be 32-bit so it uses AcroPDF.dll is currently the most reliable workaround.
Typical options:

• Ship a 32-bit build
• For .NET: enable Prefer 32-bit (or compile x86)

---

3) Operational workarounds (when you must stay 64-bit)​

A) Uninstall KB5074109 (last resort, but confirms root cause)​

If removing KB5074109 immediately restores AcroPDF64 hosting, that’s strong evidence for a Windows regression.
Trade-off: you lose January 2026 security fixes on that machine, so this should be scoped/temporary.

B) Replace the in-form PDF rendering approach​

If you can change the software:

• Use WebView2 and render PDFs via Edge’s PDF engine (common modern workaround)
• Use a dedicated PDF SDK/viewer component that doesn’t rely on the legacy Adobe ActiveX control

(Adobe’s ActiveX approach is legacy tech and tends to break when Windows hardens COM/ActiveX hosting surfaces.

---

4) What I need from you to help prove and document this (and get it traction)​

If you paste these details, I can help you produce a clean repro + likely escalation path:

1. Windows version + build (e.g., 24H2 build 26100.7623) and confirmation KB5074109 installed
2. Adobe product + exact version (Reader vs Acrobat; 64-bit vs 32-bit installer)
3. Host app details:
   • Language/stack (Delphi/VB6/.NET/WPF/MFC/etc.
   • Is the host process definitely 64-bit?
4. Exact failure mode:
   • Error code/message, or screenshot
   • Any Event Viewer crash/faulting module entries (name + exception code)
5. Does re-registering AcroPDF64.dll change anything?

If you can share just the Event Viewer “faulting module” line (or the COM error HRESULT), that alone often tells us whether this is COM activation blocked vs runtime crash inside the control.

---

5) Why this is plausible with KB5074109​

KB5074109 is already associated with multiple “compat/hardening style” regressions (AVD auth, Explorer behavior, etc..
A break that only affects 64-bit ActiveX hosting but not the 32-bit path strongly suggests a change in a 64-bit-only COM/ActiveX hosting surface, mitigation, or security boundary.
Send the details above (especially the HRESULT or Event Viewer crash info), and I’ll help you narrow it to a specific failing layer and assemble a “minimal repro” you can post/submit (Feedback Hub + MS Q&A + Adobe) so it’s more likely to be acknowledged/fixed.