Corporate IT teams are discovering a punishing side effect of the Windows 11 24H2 update: machines where the WinHTTP Auto-Proxy (WPAD) service has been deliberately disabled for security reasons are suddenly losing all network connectivity. Network adapters appear briefly, then vanish, leaving users stranded with APIPA addresses and no path to the internet. Microsoft has released some targeted fixes, but responses from the company indicate that a full rollback of the underlying dependency change may not arrive quickly—if at all.

This dual-pronged problem, which also includes DHCP option parsing failures, has triggered emergency remediation efforts across managed fleets. The root issue traces back to a surprise dependency inside Windows Connection Manager (WcmSvc). Starting with 24H2, WcmSvc now requires WinHttpAutoProxySvc to be running. For organizations that hardened Windows by disabling WPAD—a well-known attack vector—this silent dependency turns a best-practice security configuration into a self-inflicted outage.

What’s broken and who feels the pain

The symptoms are unmistakable and brutal. On affected clients, network adapters show as disabled within seconds of login, IPv4 configuration falls back to 169.254.x.x, and connectivity never establishes. Applications that expect a corporate proxy suddenly act as if no proxy exists, bypassing policy enforcement. The trouble began surfacing shortly after the Windows 11 2024 update (version 24H2, starting with OS build 26100) rolled out, and it has continued through subsequent cumulative updates, including the February 2025 security patches.

Microsoft’s own release-health dashboard acknowledges two distinct but overlapping issues. The first is a DHCP client regression in which duplicate or mis-encoded DHCP options—especially option 43 and option 252—prevent IPv4 from fully negotiating. The second, more insidious problem is the WcmSvc-to-WinHTTP dependency. Administrators who applied Group Policy to set the WinHttpAutoProxySvc startup type to “Disabled” found that their previously stable machines could no longer authenticate, enroll devices, or even reach a sign-in screen.

This isn’t a niche edge case. Reports from large enterprises, government agencies, and managed education networks have poured into Microsoft Q&A, Tech Community forums, and third-party threads. While not every 24H2 machine is affected—many home users and unmanaged devices sail through—the impact is severe for precisely the kind of locked-down, policy-driven environments that dominate the enterprise landscape.

A dependency that security teams never saw coming

For years, Microsoft’s own security guidance encouraged IT teams to disable WPAD. The Web Proxy Auto-Discovery protocol relies on DHCP or DNS to locate a PAC file, and it has been a favorite target of man-in-the-middle attackers who spoof WPAD responses to redirect all traffic. Best-practice baselines from DISA STIGs and CIS Benchmarks often call for disabling WinHttpAutoProxySvc outright. Many organizations also remove WPAD from their DHCP scopes and block outbound PAC retrieval at the firewall.

Windows 11 24H2 upended that assumption. The Windows Connection Manager service, which brokers link-layer connectivity decisions, now lists WinHttpAutoProxySvc as a required dependency in its service configuration. When WcmSvc starts—typically at boot or during user logon—it checks for its dependent services. If WinHttpAutoProxySvc is set to Disabled, WcmSvc itself fails to start cleanly. The result is a cascading failure: WcmSvc marks network adapters as disabled, the DHCP client never obtains a lease, and the machine drops into isolation.

The timing is especially cruel for Intune and Autopilot scenarios. A freshly enrolled device that pulls 24H2 during OOBE can end up with no network stack before it ever completes provisioning, leaving it bricked in a pre-login state. IT teams accustomed to zero-touch deployment have been forced to resort to wired connections, static IPs, or pre‑24H2 images just to get devices operational.

The DHCP facet: duplicate options sink connectivity

Alongside the WPAD dependency, a second bug nibbles at the DHCP client. In some on‑premises DHCP configurations, the same option number is defined twice—once as a string, once as a binary blob—or the option’s data type is encoded differently than expected. Before 24H2, the Windows DHCP client was tolerant of such quirks. After the update, however, a duplicate option 43 (Vendor Specific Information) or 252 (WPAD) can cause the client to reject the entire DHCP offer, leaving the interface with no IP at all.

Network teams have found that simply re‑encoding problematic options from “text” to “string” on their DHCP servers, or removing duplicate entries, resolves the IP acquisition issue for many clients. Microsoft released a specific patch in November 2024 (KB5046617) that addressed the “duplicate DHCP options” case, but subsequent cumulative updates appear to have reintroduced the sensitivity, and many admins report the fix isn’t universal across all DHCP server implementations.

Triage and immediate workarounds

If you’re staring at a disabled NIC right now, three fast paths can bring a device back online—each with its own trade‑offs.

Option 1: Re‑enable WinHttpAutoProxySvc (temporary)

Run these commands from an elevated prompt:

sc config WinHttpAutoProxySvc start= auto
sc start WinHttpAutoProxySvc

Or set the registry value HKLM\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc\Start to 2 (automatic) and reboot. This restores the missing dependency and stops WcmSvc from disabling adapters. The obvious downside: you’ve just re‑enabled a service you intentionally disabled, reopening the WPAD attack surface.

Option 2: Remove the dependency (riskier but permanent)

Edit the registry at HKLM\SYSTEM\CurrentControlSet\Services\WcmSvc. Under the DependOnService multi‑string value, delete the entry for WinHttpAutoProxySvc. Reboot. WcmSvc will start without it. Caution: modifying service dependencies is unsupported without a case-by-case validation; test thoroughly and deploy via a controlled GPO or script.

Option 3: Apply DHCP workarounds

For pure DHCP failures, inspect the scope options on your DHCP server. Look for option 43 or 252 defined more than once. Change the encoding from “Text” to “String” or eliminate duplicates. As a stopgap, assign static IPs or reservations to critical boxes. Also ensure you’ve applied the latest cumulative update (at minimum KB5046617 or later), which contains the official fix for duplicate DHCP options.

Curbing the security fallout

Re‑enabling WPAD wholesale is not an acceptable long‑term strategy for security-conscious shops. If you must turn the service back on, lock it down. One method: configure DHCP option 252 to point to a tightly controlled internal PAC file, or even to http://127.0.0.1/wpad.dat on the local machine, preventing any actual PAC retrieval. Combine that with firewall rules that block outbound PAC requests to the internet from all untrusted networks. Group Policy can also restrict automatic proxy discovery to domain‑joined networks only.

For many organizations, however, the cleaner path is to eliminate WPAD entirely and move to explicit proxy delivery. Use Group Policy or MDM profiles to set the proxy server and PAC URL directly for Edge and legacy Internet Explorer, and import those settings into WinHTTP with:

netsh winhttp import proxy source=ie

That way the WinHTTP stack always has a valid proxy pointer without ever invoking auto‑discovery.

Why a full revert isn’t on the table

The “may never be fixed” alarm came from responses Microsoft engineers posted in public forums and Q&A threads. While no official statement uses that phrase verbatim, the tone of those replies—acknowledging design constraints, compatibility trade‑offs, and the need for architectural work—suggests that a simple rollback is not in the cards. This dependency change may be collateral from a platform hardening initiative, perhaps aimed at tightening how network‑layer components interact. Undoing it could destabilize other fixes or reintroduce older security gaps.

Microsoft’s incremental approach is telling: they’ve fixed the duplicate DHCP option bug (multiple times, it appears) and have posted specific workaround guidance for the WinHTTP dependency, but a sweeping reversion hasn’t materialized. Enterprise architects should plan on a future where WcmSvc continues to require WinHttpAutoProxySvc, and adapt their proxy strategy accordingly.

Preparing for the long haul

Smart IT teams are treating this not as a one-off bug but as a permanent environmental constraint. Immediate actions:

  • Block the rollout. Use WSUS, Intune feature‑update rings, or SCCM to pause Windows 11 24H2 deployment until you’ve confirmed your proxy configuration won’t trigger the dependency failure.
  • Script the fix. Deploy PowerShell scripts via GPO that either set WinHttpAutoProxySvc to Manual or remove it from WcmSvc’s dependency list. Have those scripts ready for field technicians.
  • Inventory your fleet. Tag device models and driver versions that show the highest failure rate. Reports suggest Intel wireless adapters (AX200/AX210 series) and certain Dell/Lenovo OEM images are overrepresented. Engage your vendor for validated driver updates.
  • Move to explicit proxy. Accelerate any active projects to replace WPAD with direct‑config proxy settings. This removes the core conflict and future‑proofs against similar surprises.
  • Monitor release health. Bookmark the Windows 11 24H2 known-issues page and watch for KB articles referencing DHCP or network fixes. Validate each in a test lab before pushing to production.

For Intune‑managed environments, enable “Update ring policy – Allow Windows update during OOBE” so that devices pick up the latest quality fixes before user sign‑in, reducing the chance of hitting a known boot‑blocking state.

Communicating with users and support staff

Arm your helpdesk with a simple, non‑technical script: “If your laptop shows No Internet after a recent update, try a wired connection or contact IT. We’ll get you working within minutes.” Don’t ask end users to edit the registry. Teach your 1st/2nd‑line support to check the OS build (winver → 26100.x), inspect the WinHttpAutoProxySvc state (Get-Service WinHttpAutoProxySvc), and quickly toggle the service or push the pre‑packaged remediation script.

The bottom line

Windows 11 24H2 introduced a hard dependency on a service that many security‑conscious enterprises had rightly disabled. The fallout—vanishing NICs, broken enrollment, and lost connectivity—is not a passing glitch. Microsoft’s engineering choices suggest that the landscape has shifted, and IT teams must shift with it. Stop relying on WPAD, cement explicit proxy configuration, and get ready to remove WinHttpAutoProxySvc from WcmSvc’s dependency tree. The fix may not come from Redmond; it will come from deliberate, well‑tested policy changes in your own environment.

If you’re navigating this today, start with the pilot test plan: take five to ten representative devices, apply the dependency‑removal registry change via GPO, and measure stability over a week. Only then unblock Windows 11 24H2. The stakes are too high to hope for a magical update that makes everything behave like 23H2 ever again.