Windows 11 KB5066835 Breaks L Connect 3 UI - Quick Rollback Guide

Lian Li owners reporting a disappearing L‑Connect 3 UI after Patch Tuesday’s October cumulative (KB5066835) now have a practical — if temporary — workaround: pause Windows Update, remove KB5066835, and reboot.

Background / Overview​

Microsoft shipped the October 14, 2025 cumulative update for Windows 11 as KB5066835 (OS builds 26100.6899 and 26200.6899). The package contains security fixes, quality improvements and small feature changes across the platform. Microsoft bundles a servicing stack update (SSU) alongside the LCU in this monthly cumulative, and the release notes explicitly explain that removing the LCU portion may require DISM/remove‑package workflows because the SSU component is persistent.
Shortly after the update rolled out, Lian Li users began reporting that their L‑Connect 3 application showed an empty screen or failed to enumerate any Lian Li hardware — fans, controllers, HydroShift devices and the like — even though the hardware still appeared in Device Manager and the devices functioned (spinning fans, RGB active). Community threads and Lian Li’s own support staff traced the regression to the October cumulative and offered a stepwise rollback as an interim fix.
This article explains the symptoms, the verified and likely causes, the safe sequence of mitigations, and the trade‑offs — especially the security implications — for users and administrators who depend on L‑Connect and Lian Li hardware.

---

What’s happening (symptoms and scope)​

Core symptom: L‑Connect 3 shows nothing​

• After installing KB5066835 (October 14, 2025 cumulative), many users find L‑Connect 3 launches but shows no system info or devices — a blank interface that behaves as if the app cannot access the underlying hardware abstraction or its own device drivers. Community reports show the USB‑connected receivers and controllers still present in Device Manager, and hardware continues to operate physically, but the app’s device list is empty.

Who’s affected​

• The problem appears in Home and enthusiast systems rather than being limited to a single GPU vendor: both NVIDIA and AMD users reported issues, making a GPU driver the unlikely universal culprit. Some users observed the symptom immediately after a GPU driver reinstall, but broader cross‑vendor reports point to the Windows update as the common denominator.

Variability in outcomes​

• Some users fixed the problem by uninstalling KB5066835 and then installing or reinstalling L‑Connect 3, or by removing and reinstalling the receiver’s USB driver. Others needed additional steps — removing other recent updates, performing a Windows software reset, or applying a local firmware update for the Lian Li device — to regain connectivity. Not every system responds the same way.

---

Early verification and cross‑checks​

Two independent lines of evidence back the association between the update and the L‑Connect failures:

• Microsoft’s October cumulative (KB5066835) is the shipping update for Windows 11 on October 14, 2025; its release notes and servicing guidance confirm the package contents and warn about SSU+LCU uninstall behavior. That establishes the update’s presence and packaging characteristics.
• Community reporting and on‑vendor engagement (Lian Li support posting within their Reddit community) describe the same symptom and provide a consistent interim remediation — pause updates, uninstall KB5066835, reboot, then test L‑Connect 3 — which Lian Li’s staff explicitly recommended while they investigate. These community posts are active and contemporaneous to the update rollout.

Where claims go beyond the observable correlation (for example, why a cumulative change breaks a specific vendor’s app), the available public data does not yet prove a single root cause; that remains under investigation by Lian Li and the community. Treat those diagnostics as hypotheses until a vendor patch or Microsoft KIR/official fix is published.

---

Why uninstalling KB5066835 can help — and what it does not prove​

Uninstalling KB5066835 returns many affected L‑Connect installations to working order. This strongly suggests the update altered an OS‑level behavior or API path that L‑Connect relies on to enumerate or access Lian Li devices.
Possible, but unproven, technical mechanisms include:

• A change that affects user‑mode enumeration APIs or permissions for device access (e.g., a tightened access control path, a changed device class behavior, or subtle driver load ordering differences).
• A servicing‑level change in the SSU that altered how certain device drivers or user‑mode device providers are enumerated during login.
• A collision with other drivers or third‑party software triggered by the update’s file/driver bumps.

None of those possibilities is confirmed publicly; the only verifiable fact from community reporting is that removing the October cumulative restores L‑Connect functionality for many users. Consider that correlation, not a formal root cause analysis.

---

Step‑by‑step: the pragmatic rollback / recovery sequence​

These steps reflect Lian Li’s suggested workaround plus general Windows rollback best practice. They are ordered from least invasive to more involved.

1. Pause automatic updates (prevent reinstallation)​

• Open Start → Settings → Windows Update.
• Click Pause updates and choose 2 weeks (3 weeks if you want extra buffer).
• Why: pausing prevents Windows Update from immediately reinstalling the problematic cumulative after you remove it. Lian Li explicitly recommended this as the first action.

2. Uninstall KB5066835 (the October cumulative)​

• Settings → Windows Update → Update history → scroll → Uninstall updates.
• In the list, locate KB5066835, click Uninstall, and follow prompts. The PC will restart.
• After the restart, relaunch L‑Connect 3 and check whether devices reappear.
• Note: because Microsoft bundles the SSU with the LCU, some removal operations require DISM if the package was combined in a way that wusa.exe cannot fully reverse. Microsoft documents DISM/remove‑package as the supported way to remove the LCU component if the SSU+LCU combination prevents standard GUI uninstall behavior.

3. If L‑Connect still shows nothing: quick troubleshooting checklist​

• Reinstall L‑Connect 3 (uninstall, reboot, fresh install of latest L‑Connect 3).
• Disconnect the Lian Li USB receiver, uninstall its entry from Device Manager (including driver deletion if prompted), reboot, then plug it back in.
• Apply firmware updates for your Lian Li device using Lian Li’s local firmware update tool (download firmware for your device from Lian Li’s support site, then use L‑Connect’s Update → Local option to flash). Some users reported success with local firmware updates after the rollback.
• As a last resort, run Windows Reset > Keep my files (this resets system software while retaining personal files). Several users reported a Windows software reset resolved persistent cases where uninstalling the KB did not.

4. Advanced removal (enterprise / power‑user)​

• If the uninstall GUI fails due to combined SSU/LCU packaging, use DISM to list packages and remove the LCU by package name:
• Open an elevated command prompt.
• Run: DISM /Online /Get‑Packages | findstr KB5066835 (capture the package identity).
• Remove with: DISM /Online /Remove‑Package /PackageName:<full-package-identity>
• Caution: DISM manipulates servicing components. Run DISM only if you are confident and have verified system backups or a recovery image. Microsoft’s KB explains this path and the caveats around SSUs.

---

Important caveats and security trade‑offs​

You will lose the October security fixes until you reinstall a corrected cumulative​

• Uninstalling KB5066835 removes the LCU portion that includes that month’s security patches. That temporarily re‑exposes the system to the vulnerabilities fixed by that cumulative until a corrected build is installed.
• For many users with desktop, personal systems, the short‑term risk may be acceptable compared with the immediate loss of device control; for business systems or internet‑exposed hosts, weigh the trade‑off carefully with your security posture and compensating controls (firewall, limited network exposure, EDR).

Removing SSU components is delicate or impossible via the normal GUI​

• Combined SSU+LCU packages mean the servicing stack update is persistent; typical wusa uninstall is insufficient in some configurations. DISM remove‑package is the supported but advanced method. Recovery images or a full system snapshot are the safest rollback options in managed environments. Microsoft’s guidance is explicit about this complexity.

Blocking the KB temporarily is necessary​

• After rollback, pause updates or use Microsoft’s show/hide updates tool (wushowhide.diagcab) to prevent Windows from redownloading the same KB automatically. IT admins should use WSUS/Intune controls or Known Issue Rollback (KIR) policies in managed estates. Community reports show the update can reapply on reboot if update flow isn’t blocked.

---

If the uninstall didn’t help: additional troubleshooting steps that users reported​

• Try uninstalling other recent updates in temporal order — some users found another cumulative (installed around the same time) to be the offender. The ordering makes this a trial‑and‑error task, so document what you remove.
• Remove and reinstall the USB receiver driver for wireless fans/controllers: unplug, uninstall device in Device Manager (check “Delete the driver”), reboot, then plug back in. Several users recovered devices this way.
• Perform a Windows software reset (Settings → System → Recovery → Reset this PC → Keep my files). This is more aggressive but has been reported to resolve stubborn cases where L‑Connect still would not enumerate devices. Use this only after backups and when less invasive steps fail.
• Install device firmware locally via L‑Connect’s firmware update option: download firmware from Lian Li’s site and apply via L‑Connect → Settings → Update → Local. A number of users reported firmware refresh restored enumeration.

---

Vendor response, timeline and what to expect next​

• Lian Li’s official support team acknowledged the problem publicly in community threads and provided the uninstall/pause guidance as a temporary workaround while they investigate the underlying compatibility issue. That statement — and the suggested steps — came directly from Lian Li staff engaging with affected users.
• Lian Li is likely to pursue one or more of these paths: issue an L‑Connect update to bypass the changed OS behavior, publish a firmware patch if the device driver needs an update, or coordinate with Microsoft if the regression is at the OS level and requires a Microsoft fix or KIR.
• Microsoft may issue either a hotfix or absorb a correction into a subsequent cumulative. In previous servicing cycles, Microsoft has shipped targeted fixes or advisories when third‑party apps lost access to system resources after a cumulative; it’s reasonable to expect a follow‑up if the issue proves to affect a broader set of peripherals. Keep an eye on Microsoft’s Release Health and the relevant vendor channels for official patches.

---

Risk assessment for different audiences​

Home users and enthusiasts​

• Balance convenience vs. security: uninstalling the KB is a practical stopgap if loss of device control disrupts daily use. Pause updates after rollback and monitor Lian Li channels for an official patch before reapplying the cumulative. Back up critical data before any rollback or reset.

Power users and system builders​

• If you maintain images or manage multiple enthusiast rigs, test the rollback/restore flow on a spare machine before applying it widely. Document the DISM package identities and be prepared to revert using system images if a rollback fails.

Small business and IT administrators​

• Avoid ad‑hoc uninstalls on production endpoints; instead, identify a pilot group, use update‑management tooling to block the KB on affected devices, and coordinate with Lian Li for vendor patches. If devices are critical in your fleet (e.g., workstations used for media production controlled by L‑Connect), plan mitigations that preserve security posture (network isolation, host‑level protections) while waiting for vendor or Microsoft fixes. Use Known Issue Rollback (KIR) or WSUS approvals where possible.

---

Practical checklist — the one‑page version​

• Back up critical data and create a system image.
• Pause updates: Settings → Windows Update → Pause updates (2–3 weeks).
• Uninstall KB5066835: Settings → Windows Update → Update history → Uninstall updates → select KB5066835 → Uninstall → reboot.
• Reboot and check L‑Connect 3.
• If still broken: uninstall/reinstall L‑Connect, remove/replug USB receiver, perform local firmware update, or try Windows Reset (Keep my files).
• If uninstall GUI fails or more granular removal is required, consider DISM /Remove‑Package after documenting the package name and ensuring you have recovery options.
• Monitor Lian Li channels and Microsoft Release Health for an official patch; re‑enable updates only after a confirmed fix is available.

---

What we don’t know yet (and how to treat unverified claims)​

• The precise technical root cause — which OS component or driver behavior change broke L‑Connect — has not been publicly confirmed by Microsoft or Lian Li at the time of writing. Community correlation and vendor troubleshooting point strongly at KB5066835, but a formal root cause report or an updated L‑Connect release will be required to close the case definitively. Treat any claim that pins the fault on a specific OS DLL, driver, or API as unverified until the vendor(s) publish a fix or diagnostic statement.
• Some users reported that reinstalling GPU drivers or performing unrelated driver updates triggered the visible failure — but the cross‑vendor distribution of reports (AMD and NVIDIA systems) still indicates the Windows cumulative as the common factor. Anecdotes that place the blame exclusively on a GPU driver update should be regarded as situational unless corroborated widely.

---

Final verdict and recommended posture​

The October 2025 cumulative (KB5066835) introduced a regression that, for many Lian Li users, prevented L‑Connect 3 from detecting hardware. Lian Li’s support team and multiple user reports independently point to the same temporary mitigation: pause Windows Update, uninstall KB5066835, and reboot. That sequence restores functionality for a majority of reported cases, but it is a stopgap that reduces the device’s security posture until a patched cumulative or vendor update is available.
Recommendations going forward:

• If you depend on L‑Connect daily and cannot tolerate a blank app, follow the rollback steps above after backing up your data and pausing updates.
• If you prioritize staying fully patched, avoid uninstalling the cumulative and wait for a coordinated fix from Lian Li or Microsoft while using manual device workarounds where possible (driver toggles, temporary alternate outputs).
• For administrators, adopt a cautious pilot‑and‑monitor approach and use update‑management controls (WSUS/Intune/KIR) rather than emergency uninstalls at scale. Thoroughly test rollback strategies (DISM and image restores) in a lab before applying them to production endpoints.

For Lian Li owners who are troubleshooting now, the community threads are active and Lian Li’s support staff are responding directly to posts — that’s the fastest place to see status updates, incremental diagnostics, and new firmware or app builds as they arrive.

---

The silver lining: once fixed, this kind of regression typically receives a targeted vendor update or a Microsoft follow‑up within a short window. Until then, use the measured rollback steps above, keep backups, and monitor official channels for the definitive patch.

---

Source: PiunikaWeb Lian Li L-Connect blank after Windows 11 Oct patch? Here's the fix

 

[ChatGPT]

Microsoft has issued an emergency out‑of‑band response after the October cumulative update for Windows 11 (delivered as KB5066835) produced a high‑impact regression that left USB keyboards and mice unresponsive inside the Windows Recovery Environment (WinRE), prompting a rapid remediation roll‑out and urgent guidance for users and administrators.

Background​

The October 14, 2025 monthly cumulative for Windows 11 (cataloged as KB5066835, OS builds ~26100.6899 / 26200.6899 depending on branch) included routine security hardenings and quality fixes but also coincided with Safe OS dynamic updates that refresh the on‑device WinRE image. Within days, multiple independent reports demonstrated a consistent symptom: when an affected machine booted into WinRE the interface displayed normally but USB input devices (keyboard and mouse) produced no response, even though those same devices worked normally in the full Windows desktop. Microsoft marked the issue Confirmed on its Windows Release Health (Known Issues) dashboard and stated engineers were preparing a fix.
This is not a minor UX glitch. WinRE is the built‑in “Safe OS” recovery image used for Startup Repair, Reset this PC, Safe Mode, Command Prompt and firmware access. When WinRE is non‑interactive, users and IT technicians lose the primary, on‑device recovery path — a serious operational risk for devices that fail to boot.

---

What went wrong: technical symptoms and likely cause​

The observed symptom​

• Affected devices boot into WinRE and display the normal recovery tiles and menus, but:
• No mouse pointer appears and USB mouse movement is not registered.
• Keyboard presses do not navigate menus or accept input.
• The same USB peripherals continue to function normally once the full Windows desktop loads.

The likely technical vector​

WinRE runs from a compact, trimmed image (commonly stored as winre.wim) with a deliberately minimal driver set to keep the Safe OS small and reliable. Evidence from community recoveries (where replacing the on‑device winre.wim with a known‑good copy restored input) points to a mismatch or mispackaged driver variant inside the Safe OS image rather than a universal USB hardware failure. That suggests the update path supplied an incorrect driver set or wrong variant for certain USB host controllers (for example, xHCI variants) in the WinRE context, which prevented initialization inside the compact environment. Microsoft has not published a granular post‑mortem naming a single binary as the root cause, so any specific file‑level attribution remains provisional.

---

Timeline: from rollout to remediation​

• October 14, 2025 — Microsoft ships the October cumulative update for Windows 11 as KB5066835. Many devices also receive companion Safe OS dynamic updates intended to refresh the recovery image.
• October 15–17, 2025 — Community and enterprise channels produce reproducible reports: WinRE UI appears but USB input is dead. Multiple vendors and help forums document similar reproductions across hardware.
• October 17–18, 2025 — Microsoft lists the issue on the Windows Release Health (Known Issues) dashboard and marks it Confirmed, promising an upcoming solution.
• Following days — Microsoft prepares an out‑of‑band (OOB) remediation and deploys targeted mitigations (Known Issue Rollback and an emergency package) to impacted servicing families. Field manifests and community telemetry show targeted offers and an MSU/catalog distribution for the emergency fix reaching devices.

---

Microsoft’s response: emergency patching and KIR​

Microsoft responded with the standard set of emergency mechanisms used when a security/quality rollup causes a regression that undermines recovery:

• Known Issue Rollback (KIR): where possible, Microsoft pushed KIR to neutralize the problematic change without removing the security content of the cumulative update. This is a targeted mitigation that can be applied selectively to populations of devices.
• Out‑of‑band cumulative (hotfix): Microsoft published an emergency package (reported in the field as KB5070773 for affected servicing branches) that restores the expected Safe OS binary set or driver variants inside winre.wim so USB host controllers initialize properly in WinRE. The package was distributed via Windows Update and the Microsoft Update Catalog/MSU channels, with some distributions bundling the Servicing Stack Update (SSU) alongside the Latest Cumulative Update (LCU) to ensure servicing stack alignment.
• Guidance for admins: vendors and community reporting emphasized using the official OOB package or KIR rather than manual LCU uninstalls because combined SSU+LCU bundles can complicate rollback semantics.

Microsoft’s Release Health page and the KB entry for the October cumulative provide the authoritative confirmation that the issue existed and that a fix was being prepared.

---

How the fix works (technical summary)​

Because the fault surface was isolated to the pre‑boot Safe OS image, the emergency remediation focuses on restoring the correct recovery image and driver set rather than altering desktop driver behavior. The vendor remedies observed in manifests and community analysis take one of two forms:

• Install a corrected Safe OS Dynamic Update that refreshes the on‑device winre.wim with the appropriate USB driver variants and binaries, or
• Apply a combined SSU + LCU package that corrects servicing stack ordering and ensures the recovery artifacts on the recovery partition are reconciled with the expected Safe OS image.

Important operational detail: when the fix is packaged as SSU+LCU, uninstalling the LCU alone may not revert the recovery image to its prior contents because SSU changes can alter servicing behavior. That’s one reason official remediation via Microsoft’s OOB package or KIR is the recommended path for most administrators.

---

Impact: who was affected and why it mattered​

• Affected products: Windows 11 versions 24H2 and 25H2 (client) and some Windows Server 2025 servicing channels. The originating update was cited as OS Build 26100.6899 in Microsoft’s known issues note.
• Hardware most at risk: systems that rely entirely on USB input (USB‑C / USB‑3 host controllers) with no PS/2 fallback. Laptops, small form factor desktops and devices without legacy ports were the most operationally impacted because there was no alternate input path in WinRE.
• Operational consequences:
• For home users, inability to use WinRE can make common recovery tasks impossible without external media or physical service.
• For helpdesks and enterprise fleets, a non‑interactive WinRE complicates hands‑off remediation and increases the likelihood of physical technician intervention, reimaging or device replacement.
• For developers and CI systems, the October update also produced unrelated localhost/HTTP.sys regressions in some environments, compounding the immediate impact on productivity workflows.

---

Immediate mitigations and step‑by‑step guidance​

The community and enterprise responders published a hierarchy of mitigations ranked by safety and risk. The conservative approach is prioritized here.

Recommended (for most users and admins)​

• Check Windows Update and the Microsoft Update Catalog for the out‑of‑band offering (and apply it when available). Installing Microsoft’s emergency package or receiving KIR is the least risky remediation.
• Create validated external recovery media immediately (bootable Windows 11 ISO / WinPE on USB). External media most often includes a broader driver set and will usually accept USB input even when on‑device WinRE is broken.
• Pause deployment of KB5066835 in recovery‑critical rings (devices that require reliable recovery) until the fix is validated in a pilot ring. Use WSUS, ConfigMgr, Intune or your management tooling to control rings.

Advanced (for experienced technicians only)​

• Inventory WinRE state at scale: run reagentc /info to capture WinRE registration, path and version across endpoints. Keep checksums and offline copies of known‑good winre.wim images per hardware baseline.
• Replace the local winre.wim with a known‑good copy from a matching ISO (risky): disable WinRE (reagentc /disable), back up and replace C:\Windows\System32\Recovery\Winre.wim, then re‑enable and verify. This has restored input for some devices but carries risk and should only be done with full backups and in controlled environments.
• Inject correct USB/xHCI drivers into the WinRE image via DISM (DISM /Add-Driver) and re‑commit the image. This preserves security updates but requires exact, vendor‑provided driver packages and image‑handling skill.

What not to do casually​

• Avoid ad‑hoc registry hacks or unverified scripts from community posts; there are multiple reports of risky suggestions that can brick Windows or disable recovery permanently. Microsoft and reputable outlets explicitly advised against casual tinkering.

---

Risk analysis: strengths and weaknesses of Microsoft’s response​

Strengths​

• Speed of response: Microsoft moved to acknowledge the problem publicly and prepared both a KIR and an out‑of‑band remedy within days — appropriate for an issue that undermines device recovery. Rapid OOB packages and KIR are the right operational tools when an update compromises recovery pathways.
• Targeted remediation focus: Addressing the Safe OS / winre.wim image rather than desktop drivers reduces the risk of regression in normal runtime while restoring pre‑boot capabilities — a surgical approach that protects security content while fixing recovery artifacts.

Weaknesses and residual risks​

• Bundling SSU + LCU complicates rollback: Some distribution paths include the Servicing Stack Update with the cumulative, altering rollback semantics. Uninstalling the LCU alone may not restore the earlier recovery image, which leaves administrators with awkward rollback choices. This makes KIR and official OOB packages preferable but introduces complexity for offline/manual remediation.
• Insufficient post‑mortem detail (so far): Microsoft’s public advisories confirmed the symptom and mitigation but have not published a detailed line‑by‑line root cause that identifies the precise driver binary or packaging error. Until a full technical post‑mortem is available, some attributions remain speculative. That lack of detail slows downstream vendor and OEM validation.
• Test matrix gap: The incident emphasizes that recovery environments need to be first‑class test targets in the update validation matrix. Minimal Safe OS images are inherently brittle; update pipelines that touch both desktop and Safe OS artifacts must include explicit validation on USB‑only hardware and modern host controllers.

---

Broader operational lessons and recommendations​

• Treat WinRE/WinPE validation as a standard part of update pilot cycles. Recovery paths are not optional — they must be included in QA matrices for any change that touches servicing or Safe OS artifacts.
• Maintain offline, versioned, golden winre.wim images for each major hardware profile and test external recovery media regularly.
• Leverage Known Issue Rollback and vendor OOB packages rather than manual LCU uninstalls whenever possible; KIR protects security content and simplifies remediation at scale.
• For enterprises: implement targeted pilot rings that specifically include USB‑only devices and developer machines (to catch localhost/HTTP.sys regressions), and rehearse rollback and offline remediation playbooks.

---

Verification and cross‑checks​

Key facts in this report have been verified against multiple independent sources and Microsoft’s own advisories:

• Microsoft’s Windows Release Health page documents the WinRE USB input issue associated with KB5066835 and lists affected platforms and the confirmed status.
• The official KB5066835 support article for the October cumulative confirms the update’s release date and build metadata.
• Independent technical reporting and community triage corroborated reproducible restorations via winre.wim replacement and documented the operational impact that made the incident an emergency.

Where Microsoft has not published granular root‑cause details (for example, the exact driver INF or binary line that failed inside WinRE), that absence is flagged in the analysis and any specific low‑level attribution is presented as provisional.

---

Practical checklist for IT teams (quick action list)​

• Check the Windows Release Health dashboard for the current status and KIR guidance.
• Query Windows Update / Microsoft Update Catalog for KB5070773 or OOB offerings and pilot on a small set of USB‑only devices.
• Ensure every recovery‑critical device has validated external recovery media (bootable WinPE/Windows install USB).
• Inventory WinRE images across representative hardware (reagentc /info) and compare checksums with golden images.
• Avoid manual uninstall of cumulative updates unless fully tested; prefer KIR or Microsoft’s published OOB package.

---

Conclusion​

The October 2025 Windows 11 servicing wave underlines an enduring truth of large OS maintenance: a single change in the servicing pipeline that reaches both runtime and recovery artifacts can produce outsized operational pain. Microsoft’s swift acknowledgement and use of Known Issue Rollback plus an out‑of‑band remediation were appropriate and necessary responses to an issue that disabled standard recovery workflows for many users. Still, the episode exposes weaknesses in test coverage, rollback semantics when SSU and LCU are combined, and the fragility of minimal Safe OS images running on modern USB host controllers. The pragmatic path forward for IT teams is clear: apply Microsoft’s official fix or KIR, maintain validated external recovery media and golden winre.wim images, expand update validation to include WinRE/WinPE on representative hardware, and treat recovery environments as first‑class citizens in update governance to prevent a repeat of this class of failure.

---

Source: FindArticles Microsoft Prepares Emergency Windows 11 Fix
Source: Mashable Microsoft to release emergency fix for recent Windows 11 update