Windows Hotspot Not Working: The Service That’s Usually Dead

Fast diagnosis playbook

If you’re in a hurry, don’t wander through Settings toggles like it’s a haunted house. You want to answer three questions in order: Can the Wi‑Fi stack host? Is ICS/NAT alive? Is traffic actually being forwarded?

1) First: confirm the hotspot mechanism is even available

• Check whether Wi‑Fi Direct virtual adapters exist and are enabled.
• Check whether the machine has a working Wi‑Fi adapter (sounds obvious; it’s often not).

2) Second: check the service that usually kills it

• Is Internet Connection Sharing (ICS) service running?
• Is Windows Firewall (MpsSvc) running? (ICS leans on it.)
• Is WLAN AutoConfig (Wlansvc) running?

3) Third: prove routing/NAT and DNS work end-to-end

• Does the hotspot adapter have a private IPv4 address (usually 192.168.137.1)?
• Do clients get DHCP, default gateway, and DNS?
• On the host, can you see NAT configured and traffic counters moving?

Do those in that order. Otherwise you’ll “fix” DNS when the adapter never created, or you’ll reset the network stack when a single service is Disabled by policy.

What Windows hotspot actually is (and what it isn’t)

Windows Mobile hotspot is a small router impersonation stack:

• Wi‑Fi Direct / SoftAP layer creates a virtual access point interface.
• ICS (SharedAccess) glues that virtual adapter to the upstream connection, runs DHCP-ish behavior, and configures sharing.
• NAT translates traffic from your private hotspot subnet to the upstream interface.
• Firewall rules allow the right flows. If firewall services are broken, ICS tends to fail in interesting ways.
• DNS handling is often “good enough” until VPNs and corporate endpoint agents show up with their own ideas.

What it is not: a full featured router appliance. It has brittle dependencies, it changes behavior across Windows versions, and it tends to assume your network stack isn’t being “managed” by third-party software.

Operational truth: if you treat Windows hotspot as a last-mile emergency bridge and not a strategic network component, you’ll be much happier. When you must rely on it, you need fast triage and reproducible fixes—hence this guide.

One paraphrased idea worth pinning to your monitor, attributed to John Allspaw: Reliability comes from how you respond to failure, not from pretending failure won’t happen.

Interesting facts and historical context (because Windows didn’t invent NAT yesterday)

1. ICS predates “Mobile hotspot” UI by years. Internet Connection Sharing has existed since the Windows XP era, long before the modern Settings app toggle made it look simple.
2. Hosted Network vs Wi‑Fi Direct: older Windows builds leaned on “Hosted Network” capabilities; newer ones largely shifted to Wi‑Fi Direct/SoftAP implementations depending on driver support.
3. 192.168.137.0/24 is the classic ICS subnet. When you see 192.168.137.1 on a virtual adapter, you’re usually looking at ICS doing its default thing.
4. ICS and the firewall are coupled. Break the Windows Firewall service, and ICS often fails to start or won’t forward traffic correctly.
5. Corporate VPNs changed the game. Split-tunnel policies, forced DNS, and NDIS filter drivers have a habit of “helping” your hotspot into non-functionality.
6. Hyper-V and virtualization can complicate adapter bindings. Virtual switches and bridge drivers can reorder or rename interfaces, confusing sharing configuration.
7. Power management is a silent killer. Wi‑Fi adapters on laptops are regularly told to “save power,” which is adorable right up until you’re trying to be an access point.
8. Windows updates can reset service startup types. It’s not common, but it’s common enough to be in every incident playbook.

Joke #1 (short, relevant): Windows hotspot is like a meeting room projector: it works perfectly until someone needs it.

The service that’s usually dead: ICS (SharedAccess)

If your hotspot starts then stops, or never starts, or shows “No internet” for clients while your laptop is fine, assume SharedAccess is stopped, disabled, or unable to bind to the right adapter.

ICS is more than a service toggle. It’s a configuration engine that:

• decides which interface is “public” (upstream) and which is “private” (hotspot),
• sets a private subnet and assigns the hotspot adapter an IP,
• enables NAT behavior,
• punches firewall holes to allow forwarding and DHCP-like behavior,
• can be confused by multiple upstreams (Wi‑Fi + Ethernet + VPN + cellular).

What kills it most often:

• Service startup type set to Disabled (by policy, “debloat,” or security hardening done without understanding dependencies).
• Firewall service not running (or a third-party firewall product that half-removes it).
• VPN client installing NDIS filter drivers that change routing and DNS in ways ICS can’t reconcile.
• Wi‑Fi driver not supporting the required SoftAP/Wi‑Fi Direct features, or the virtual adapter being hidden/disabled.
• Network stack corruption after updates, driver changes, or aggressive “network optimizer” software.

Practical tasks: commands, outputs, decisions (12+)

These are the tasks I actually run when I’m on the hook for getting a hotspot working in a production-ish environment (labs, incident bridges, field devices). Every task includes: a command, what output means, and what decision you make next.

Task 1: Check ICS service state (SharedAccess)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name SharedAccess | Format-List Status,StartType,Name,DisplayName"
Status      : Stopped
StartType   : Disabled
Name        : SharedAccess
DisplayName : Internet Connection Sharing (ICS)

Meaning: ICS is stopped and disabled. Hotspot will typically fail to start, or will start then stop.

Decision: Set startup type to Manual/Automatic and start it. Also figure out what disabled it (policy, security baseline, “debloat”).

Task 2: Enable and start ICS

cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name SharedAccess -StartupType Manual; Start-Service -Name SharedAccess; Get-Service SharedAccess"
Status   Name               DisplayName
------   ----               -----------
Running  SharedAccess       Internet Connection Sharing (ICS)

Meaning: ICS is now running.

Decision: Try enabling Mobile hotspot again. If it still fails, check firewall service and WLAN AutoConfig next.

Task 3: Verify Windows Firewall service (MpsSvc)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name MpsSvc | Format-List Status,StartType"
Status    : Stopped
StartType : Disabled

Meaning: Firewall service is disabled/stopped. ICS commonly depends on it and can fail even if SharedAccess is “Running.”

Decision: Re-enable MpsSvc, then restart SharedAccess.

Task 4: Re-enable Firewall service and restart ICS

cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name MpsSvc -StartupType Automatic; Start-Service MpsSvc; Restart-Service SharedAccess; Get-Service MpsSvc,SharedAccess | Format-Table Name,Status,StartType"
Name        Status  StartType
----        ------  ---------
MpsSvc      Running Automatic
SharedAccess Running Manual

Meaning: Core dependencies are up.

Decision: If hotspot still can’t start, move to adapter/driver checks.

Task 5: Check WLAN AutoConfig (Wlansvc)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Wlansvc | Format-List Status,StartType"
Status    : Running
StartType : Automatic

Meaning: Wi‑Fi configuration service is healthy.

Decision: If hotspot still broken, inspect adapters and virtual Wi‑Fi Direct interfaces.

Task 6: List network adapters and find the hotspot virtual adapter

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object Status,Name | Format-Table Name,InterfaceDescription,Status,LinkSpeed"
Name                         InterfaceDescription                                  Status     LinkSpeed
----                         --------------------                                  ------     ---------
Ethernet                     Intel(R) Ethernet Connection                          Up         1 Gbps
Wi-Fi                        Intel(R) Wi-Fi 6 AX201 160MHz                         Up         866.7 Mbps
Local Area Connection* 10    Microsoft Wi-Fi Direct Virtual Adapter                 Disconnected 0 bps
Local Area Connection* 11    Microsoft Wi-Fi Direct Virtual Adapter #2              Disconnected 0 bps

Meaning: Wi‑Fi Direct virtual adapters exist. That’s a good sign: Windows has something it can use to host.

Decision: If these are missing entirely, you’re likely dealing with driver support, disabled hidden devices, or group policy restrictions.

Task 7: Check whether the hotspot adapter got the expected ICS IP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Where-Object {$_.InterfaceAlias -like 'Local Area Connection*'} | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias    : Local Area Connection* 10
IPv4Address       : 192.168.137.1
IPv4DefaultGateway:
DnsServer         :

Meaning: The private side is configured (192.168.137.1). Gateway/DNS blank is normal on the private interface.

Decision: If there is no 192.168.137.1 (or no IPv4 at all), ICS didn’t configure the interface—focus back on SharedAccess, MpsSvc, and event logs.

Task 8: Check NAT configuration (on modern Windows builds)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetNat | Format-Table Name,InternalIPInterfaceAddressPrefix,ExternalIPInterfaceAddressPrefix,Active"
Name                             InternalIPInterfaceAddressPrefix ExternalIPInterfaceAddressPrefix Active
----                             ------------------------------- -------------------------------- ------
SharedAccess_NAT                 192.168.137.0/24                0.0.0.0/0                        True

Meaning: NAT exists and is active for the ICS subnet.

Decision: If no NAT object exists, ICS may not be applying correctly. Restart SharedAccess; if still absent, reset networking and re-check dependencies.

Task 9: Confirm routing table isn’t pointing clients into a black hole

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 8 | Format-Table DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix  NextHop        InterfaceAlias RouteMetric
-----------------  ------        -------------- -----------
0.0.0.0/0          192.0.2.1      Wi-Fi          25
192.168.137.0/24   0.0.0.0        Local Area Connection* 10 256
192.168.1.0/24     0.0.0.0        Wi-Fi          281

Meaning: Default route is via Wi‑Fi. The hotspot subnet is directly connected.

Decision: If default route points at a VPN interface while you expected Wi‑Fi/Ethernet, you may have a forced-tunnel VPN. Hotspot clients may lose internet unless policy allows split tunneling.

Task 10: Look at IP addressing on the upstream interface

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration -InterfaceAlias 'Wi-Fi' | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias     : Wi-Fi
IPv4Address        : 192.168.1.50
IPv4DefaultGateway : 192.168.1.1
DnsServer          : {192.168.1.1}

Meaning: Upstream looks sane.

Decision: If upstream DNS is a corporate resolver reachable only through VPN, clients may get “connected, no internet.” Decide whether to change DNS on clients, disable VPN, or adjust split tunneling.

Task 11: Check event logs for SharedAccess/ICS failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 80 | Where-Object {$_.ProviderName -match 'SharedAccess|Service Control Manager'} | Select-Object -First 8 | Format-Table TimeCreated,ProviderName,Id,LevelDisplayName,Message -Wrap"
TimeCreated           ProviderName              Id  LevelDisplayName Message
-----------           ------------              --  ---------------- ------
2/5/2026 9:18:10 AM  Service Control Manager   7000 Error            The Internet Connection Sharing (ICS) service failed to start due to the following error: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Meaning: Classic: disabled service or missing/disabled adapter dependency.

Decision: Verify adapter presence/enabled state; verify service startup types; remove “debloat” policies; then restart.

Task 12: Validate Wi‑Fi driver support (Hosted network status hint)

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 1/10/2026
    Version                   : 23.20.0.4
    Radio types supported     : 802.11b 802.11g 802.11n 802.11ac 802.11ax
    Hosted network supported  : No
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

Meaning: “Hosted network supported: No” does not automatically kill Mobile hotspot on newer Windows (Wi‑Fi Direct may still work), but it’s a warning sign: driver capabilities are limited or shifted.

Decision: If hotspot fails to start and Hosted Network is No, prioritize driver updates, OEM drivers, or a different adapter (USB Wi‑Fi that supports SoftAP).

Task 13: Reset the network stack (the controlled burn)

cr0x@server:~$ powershell -NoProfile -Command "netsh int ip reset; netsh winsock reset"
Resetting Global, OK!
Resetting Interface, OK!
Restart the computer to complete this action.
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Meaning: You’ve reset TCP/IP and Winsock. This can clear corrupted LSP/filters and bad interface state.

Decision: Reboot. Then re-check service states and adapter presence. If this is a corporate machine, expect VPN clients and endpoint agents to reassert themselves after reboot.

Task 14: Check for “helpful” VPN routes and DNS changes

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table InterfaceAlias,ServerAddresses"
InterfaceAlias                 ServerAddresses
--------------                 --------------
Wi-Fi                          {10.10.10.53, 10.10.10.54}
Local Area Connection* 10      {}
Ethernet                       {}

Meaning: Upstream Wi‑Fi DNS is set to corporate resolvers (likely via VPN or profile). If those resolvers are only reachable through a VPN interface, hotspot clients won’t resolve names.

Decision: Disconnect VPN, enable split tunneling (if allowed), or set upstream DNS back to local/ISP for the duration of hotspot use.

Task 15: Verify firewall profiles (Public/Private) aren’t sabotaging sharing

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name           InterfaceAlias NetworkCategory IPv4Connectivity
----           -------------- -------------- ---------------
CorpWiFi       Wi-Fi          Public         Internet
Unidentified   Local Area Connection* 10 Private        NoTraffic

Meaning: Upstream is Public; hotspot side is Private (fine). If both are Public with strict firewall rules, forwarding can be blocked depending on policy.

Decision: If policy permits, set hotspot side to Private. If not permitted, you’ll need a different approach (travel router, phone tethering) rather than wrestling policy.

Joke #2 (short, relevant): Some VPN clients treat “sharing internet” like a security incident. They’re not wrong; they’re just inconvenient.

Failure modes by symptom (what it’s telling you)

Symptom A: Mobile hotspot toggle flips on, then immediately turns itself off

This is the classic “dependency died” pattern. Windows UI is optimistic; the service layer is not.

• Most likely: SharedAccess stopped/disabled; MpsSvc disabled; adapter missing; driver can’t create Wi‑Fi Direct interface.
• Also common: third-party firewall/VPN has inserted filter drivers and left the stack inconsistent.

Symptom B: Hotspot turns on, clients connect, but there’s no internet

This is usually not “Wi‑Fi.” It’s routing, NAT, or DNS.

• Likely: NAT missing or not bound; upstream route goes through VPN; DNS resolvers unreachable; client got an APIPA address (169.254.x.x) due to DHCP failure.
• Less likely: upstream captive portal not completed (hotel Wi‑Fi), so the host has internet via cached sessions but new clients don’t.

Symptom C: “We can’t set up mobile hotspot” error

That message is Windows politely declining to tell you which internal component failed. Use event logs and service checks to make it talk.

Symptom D: Hotspot works after reboot, then fails after VPN connects

That’s a routing/DNS policy fight. The VPN wins, the hotspot loses, and you get to mediate with tools you probably shouldn’t need.

Symptom E: Hotspot option missing entirely

Either the device doesn’t have a compatible Wi‑Fi adapter/driver, or it’s blocked by policy (MDM/Group Policy), or you’re on a Windows edition/build with restrictions. Driver support and corporate policy are the first two suspects.

Common mistakes: symptom → root cause → fix

These are the repeat offenders I see in real fleets. The fixes are specific because vague advice is how you end up reinstalling Windows at 2 a.m.

1) Hotspot won’t start at all

Symptom: Toggle turns on then off; error about setup failing.

Root cause: SharedAccess service disabled or failing to start; sometimes due to policy or “debloat” scripts.

Fix: Set SharedAccess to Manual; start it; verify MpsSvc Running; then retry.

2) Clients connect but get “No internet”

Symptom: Wi‑Fi shows connected; browsing fails; DNS timeouts.

Root cause: Forced-tunnel VPN set as default route; DNS points to resolvers only reachable over VPN; NAT object missing.

Fix: Disconnect VPN (or allow split tunnel); restore upstream DNS; confirm Get-NetNat shows SharedAccess_NAT active.

3) Clients get 169.254.x.x addresses

Symptom: Client has APIPA address; cannot reach 192.168.137.1.

Root cause: ICS DHCP behavior isn’t functioning because SharedAccess isn’t applying config, or firewall rules block it.

Fix: Ensure SharedAccess and MpsSvc are running; reset networking; then verify hotspot adapter gets 192.168.137.1.

4) Hotspot works only on 2.4 GHz (or only on 5 GHz) and randomly disappears

Symptom: Some clients can’t see the SSID; others connect fine.

Root cause: Regulatory domain/channel issues; driver limitations; band steering confusion; client chipsets that can’t do certain channels.

Fix: Force a different band in hotspot settings if available; update Wi‑Fi drivers; avoid DFS channels by using 2.4 GHz for compatibility.

5) “I disabled Windows Firewall for troubleshooting” and now it’s worse

Symptom: You turned off the firewall and hotspot died entirely.

Root cause: Disabling the service (MpsSvc) rather than just a profile breaks ICS expectations.

Fix: Re-enable MpsSvc service, set to Automatic, start it; leave profiles controlled by policy if necessary.

6) Hotspot used to work; after driver update it stopped

Symptom: Virtual adapter missing; hotspot option present but fails.

Root cause: Driver package changed Wi‑Fi Direct/SoftAP capabilities or created a device that’s disabled/hidden.

Fix: Roll back driver; install OEM Wi‑Fi driver; check for Wi‑Fi Direct virtual adapters in Get-NetAdapter.

7) Corporate policy blocks ICS

Symptom: SharedAccess is forced disabled after every reboot; hotspot toggle missing or fails consistently.

Root cause: MDM/GPO security baseline blocks ICS to prevent bridging networks.

Fix: Don’t fight policy on endpoints. Request an exception, or use an approved travel router / phone tethering.

8) “Network reset” fixed it once, then it broke again

Symptom: Works after reset/reboot; breaks after VPN/client security agent installs updates.

Root cause: A third-party NDIS filter driver or policy reintroduces the breaking configuration.

Fix: Identify the offending component (VPN, endpoint firewall) and coordinate with IT; treat network reset as a temporary workaround.

Three corporate-world mini-stories (anonymized, plausible, technically accurate)

Mini-story 1: The incident caused by a wrong assumption

A field team needed to update firmware on a batch of lab sensors in a client site where the guest Wi‑Fi blocked peer devices. The plan was simple: engineer laptop makes a hotspot, sensors join, firmware pushed locally, done. The engineer had done it a hundred times at home.

Onsite, the hotspot toggle flipped on and immediately off. The team assumed “the Wi‑Fi card is dead” and ordered a USB Wi‑Fi dongle couriered overnight. Meanwhile, the sensors sat idle, and the project manager started composing the kind of email that looks like a resume update.

The actual problem was dumber: an endpoint hardening baseline had set SharedAccess to Disabled months earlier during a security sweep. No one connected it to Mobile hotspot because the UI doesn’t say “ICS is disabled by policy.” It just shrugs.

Fix was a policy exception applied to a specific device group, plus a runbook entry: before traveling, check SharedAccess/MpsSvc states. The USB dongle showed up the next day anyway—still in the shrink wrap, like a monument to assumptions.

Mini-story 2: The optimization that backfired

A corporate IT team decided to “speed up boot time” by disabling services that “nobody uses.” They used a script sourced from the internet—always a promising start—and rolled it to a subset of laptops as a pilot.

Everything looked fine until a sales engineer needed to share hotel Ethernet to a demo device. Hotspot failed. Then another engineer hit the same problem when setting up a quick lab network in a conference room. Both escalations landed on the same support queue within hours.

The culprit list was predictable: SharedAccess disabled; MpsSvc set to Manual and not starting; a couple of ancillary networking services delayed. The “optimization” saved a fraction of a second on boot and cost multiple people-hours plus reputational damage. The pilot was rolled back.

The lasting improvement wasn’t “never optimize.” It was: if you’re going to change service baselines, maintain a dependency map and test real workflows—including hotspot/ICS, VPN, and dock/undock scenarios. Performance gains that break core workflows are not performance gains; they’re an outage with better branding.

Mini-story 3: The boring but correct practice that saved the day

A regulated enterprise had a strict stance: no ad hoc hotspot bridging from corporate devices unless explicitly approved. That’s normal. What made it work operationally was that exceptions were handled as engineering, not as favors.

A lab team requested hotspot access for a small set of devices used in a shielded test room with no LAN drops. Security agreed, but demanded guardrails: only certain laptops, only during lab hours, and with logging. IT built a small configuration package that set SharedAccess to Manual (not Disabled), ensured MpsSvc was Automatic, and validated driver versions for the approved Wi‑Fi adapter model.

Months later, a Windows update changed network behavior on some machines. The lab laptops didn’t melt down because the configuration package ran on every check-in and repaired drift. The lab had a checklist, and the SRE on call had known-good states to compare against.

It was boring. It also worked. Most reliability wins look like “nothing happened,” which is the highest compliment production systems will ever give you.

Checklists / step-by-step plan

Checklist 1: Get hotspot working on a normal personal Windows machine

1. Reboot once (yes, really). If it fixes it, proceed anyway—intermittent wins are how problems come back.
2. Check SharedAccess is not Disabled; start it.
3. Check MpsSvc is Running and Automatic.
4. Check Wlansvc is Running and Automatic.
5. Verify Wi‑Fi Direct virtual adapters exist (Get-NetAdapter; look for Microsoft Wi‑Fi Direct Virtual Adapter).
6. Enable hotspot in Settings and watch whether it stays enabled for 30 seconds.
7. Verify hotspot adapter IP is 192.168.137.1 (or another private range if customized).
8. Connect a client; confirm it gets a 192.168.137.x address and default gateway 192.168.137.1.
9. From client test ping to 192.168.137.1, then DNS lookup, then HTTP to a known site.

Checklist 2: Corporate device (policy-aware) approach

1. Assume policy blocks ICS until proven otherwise. Check SharedAccess StartType; if it’s forced Disabled, stop and escalate properly.
2. Disconnect VPN for the test (unless policy requires always-on VPN; if so, accept that hotspot may be intentionally impossible).
3. Confirm endpoint firewall product doesn’t disable MpsSvc service. If it does, you need vendor/IT configuration, not a local hack.
4. Check event logs for Service Control Manager errors around SharedAccess and MpsSvc.
5. Don’t “fix” by uninstalling security software. That’s a career-limiting move.
6. If business-critical: use an approved travel router or a phone tether; treat Windows hotspot as non-guaranteed under corporate controls.

Checklist 3: Hotspot “no internet” triage

1. Confirm the host has internet on the upstream interface.
2. Confirm client has an IP, gateway, and DNS.
3. On host, confirm NAT exists (Get-NetNat) and hotspot adapter has 192.168.137.1.
4. If client can ping 192.168.137.1 but not resolve names, it’s DNS reachability (often VPN).
5. If client can resolve names but can’t reach IPs, it’s NAT/routing/firewall.
6. If client can’t get IP, it’s ICS/service/firewall rules.

FAQ

1) Why does Windows hotspot depend on ICS at all?

Because hotspot sharing is essentially “share this upstream connection to that private interface,” which is exactly what ICS was built to do. The UI got modern; the plumbing stayed familiar.

2) If SharedAccess is running, why does hotspot still fail?

Running isn’t the same as functioning. ICS can be running but unable to bind to the right adapters, blocked by firewall policy, missing NAT configuration, or tripping over VPN filter drivers. Check MpsSvc, adapter presence, and event logs.

3) Why do clients connect but show “No internet”?

Usually DNS or routing. The client can talk to the AP, but name resolution points at unreachable DNS servers (common with VPN), or NAT isn’t translating traffic out the upstream interface.

4) What does 192.168.137.1 mean?

It’s the default private IP Windows assigns to the shared (hotspot) interface when ICS configures sharing. Seeing it is a strong signal that ICS actually applied configuration.

5) Can I change the ICS subnet from 192.168.137.0/24?

Sometimes, but it’s not a friendly knob and behavior varies by build. If you’re colliding with an existing 192.168.137.0/24 network, the pragmatic fix is to avoid that upstream network or use a dedicated router that lets you pick subnets cleanly.

6) Why did it stop working after I installed a VPN?

VPN clients often install network filter drivers, enforce DNS settings, and rewrite routes. That can break NAT forwarding or make DNS unreachable for hotspot clients. If policy allows, test with VPN disconnected.

7) Does “Hosted network supported: No” mean hotspot can’t work?

Not always. Some modern hotspot implementations rely on Wi‑Fi Direct rather than the old Hosted Network feature. But if you’re having failures and see Hosted Network unsupported, driver limitations become a top suspect.

8) Is disabling Windows Firewall a good troubleshooting step?

Turning off a firewall profile can be informative. Disabling the Firewall service (MpsSvc) is usually destructive for ICS/hotspot. Keep the service running.

9) Why does hotspot work after reboot but breaks later?

Something reconfigures the network stack after boot: VPN auto-connect, endpoint firewall policy refresh, driver power management, or an adapter state change after sleep. Track what changes between “works” and “broken.”

10) What’s the most reliable workaround when Windows hotspot is flaky?

A small travel router or phone tethering. Not glamorous, but it’s purpose-built networking hardware instead of a desktop OS pretending to be one.

Next steps (do this, not that)

When Windows hotspot fails, don’t start by reinstalling drivers or clicking toggles until your mouse wears out. Start with the boring truth: SharedAccess (ICS) and MpsSvc are the usual corpses. Bring them back, confirm the hotspot adapter gets its private IP, then prove NAT and DNS work.

Do this:

• Check SharedAccess, MpsSvc, Wlansvc states and startup types.
• Verify virtual Wi‑Fi Direct adapters exist.
• Confirm 192.168.137.1 (or your configured private IP) appears on the hotspot adapter.
• Check NAT and routing; suspect VPN when “No internet” hits clients.
• Use event logs to replace guesswork with evidence.

Avoid this:

• Disabling the Firewall service “to see if it helps.” It usually hurts.
• Random “optimizer” scripts that disable services without dependency mapping.
• Fighting corporate policy locally. If ICS is blocked by design, escalate or use approved hardware.

If you want one operational rule: treat Windows hotspot as a dependency graph, not a button. The button is the least interesting part.