I have a Windows 10 machine set up with wired Ethernet to the Internet and using its wireless card to act as an access point using a Windows Hosted WiFi Network
Last night (early hours of 16 November 2017) a Windows 10 update was installed which prevented this working.
Rolling back to an automatic restore point from 13 November fixed the problem. However, the next evening the update was automatically reinstalled and connection sharing broke again.
Some investigation showed that the Internet Connection Sharing (ICS) service could not complete its startup. Services shows that it was stuck in the starting state. Attempting to stop the service had no effect. Killing the process stopped the service but attempting to restart the service put it into the same state.
Looking in Task Manager showed that two svchost processes were, between them, consuming one CPU's worth of activity. One was ICS the other hosted three services, most notably Windows Firewall. One was at 15% CPU and one was at 10% CPU (this system has four logical processors). It looks like they've got into a fight where one service is asking the other service to do something then going idle waiting for a response. The other processes the request and returns, presumably, a failure. At which point the first service tries again.
I've discovered that restarting the Windows Firewall service while the system is in this state clears the problem and the internet connection appears to be shared correctly. This seems to work as a temporary fix but I suspect (but have not yet tried) that
on reboot the problem will reappear. I say this as stopping and restarting the ICS service makes the problem come back (and then stopping and starting Windows Firewall again allows ICS to restart but then the network connection has to be unshared and reshared
Task Manager wait chain analysis shows that the ICS service is sometimes waiting for the other service's process.
A lot of updates were installed overnight. However, looking at the list of updates that were installed most were Office related so I would guess that one of KB4049011 or KB4048954 was responsible, probably the latter.
My system is Windows 10 Home 64 bit Version 1703 (OS Build 15063.726)
Some technical information in case it gives someone a clue (and I've got nowhere else to write it down where it might to anyone any use):
Process Explorer says that the ICS thread with the start address of sechost.dll!BuildSecurityDescriptorForSharingAccessEx+0x6c0 is consuming 10% CPU and one of the Windows Firewall (MpsSvc) threads with the start address of ntdll.dll!TpReleaseWork+0x2c0 is consuming 15% CPU.
Attempting to catch the threads in the act of doing something interesting has failed. I've always just caught them in the act of marshalling RPC records or waiting for synchronisation.
Process Monitor says that the last event it caught ICS doing before the CPU moved to MpsSvc was reading HKLM\SOFTWARE\Microsoft\Rpc\SecurityService\DefaultAuthLevel. The first thing it catches MpsSvc doing when it gets control is reading HKLM\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy.
Process Monitor grabs stacks when tracks what's going on. So, although it's not exactly at the point of failures, it might be close:
Frame Module Location Address Path
0 ntoskrnl.exe SeLockSubjectContext+0x3355 0xfffff80352f32bc5 C:\WINDOWS\system32\ntoskrnl.exe
1 ntoskrnl.exe ObOpenObjectByNameEx+0x1966 0xfffff80352f3ab96 C:\WINDOWS\system32\ntoskrnl.exe
2 ntoskrnl.exe setjmpex+0x3b63 0xfffff80352c0b413 C:\WINDOWS\system32\ntoskrnl.exe
3 ntdll.dll NtQueryValueKey+0x14 0x7ffc679d5684 C:\WINDOWS\SYSTEM32\ntdll.dll
4 KERNELBASE.dll MapPredefinedHandleInternal+0xa6e 0x7ffc6497d60e C:\WINDOWS\System32\KERNELBASE.dll
5 KERNELBASE.dll RegQueryValueExA+0x120 0x7ffc6497a8b0 C:\WINDOWS\System32\KERNELBASE.dll
6 KERNELBASE.dll SHRegCloseUSKey+0xff 0x7ffc6494e70f C:\WINDOWS\System32\KERNELBASE.dll
7 KERNELBASE.dll RegGetValueA+0x79 0x7ffc6494e809 C:\WINDOWS\System32\KERNELBASE.dll
8 RPCRT4.dll RpcSsContextLockExclusive+0xef8 0x7ffc656c1438 C:\WINDOWS\System32\RPCRT4.dll
9 RPCRT4.dll RpcSsContextLockExclusive+0xe6a 0x7ffc656c13aa C:\WINDOWS\System32\RPCRT4.dll
10 RPCRT4.dll RpcBindingSetAuthInfoExW+0x32c 0x7ffc656bb1dc C:\WINDOWS\System32\RPCRT4.dll
11 FirewallAPI.dll FWOpenPolicyStore+0xc89 0x7ffc62f05539 C:\Windows\System32\FirewallAPI.dll
12 FirewallAPI.dll FWOpenPolicyStore+0xb1b 0x7ffc62f053cb C:\Windows\System32\FirewallAPI.dll
13 FirewallAPI.dll FWOpenPolicyStore+0x4ff 0x7ffc62f04daf C:\Windows\System32\FirewallAPI.dll
14 FirewallAPI.dll FWGetGlobalConfig2+0x101 0x7ffc62f0c701 C:\Windows\System32\FirewallAPI.dll
15 FirewallAPI.dll FWOpenPolicyStore+0x1b4 0x7ffc62f04a64 C:\Windows\System32\FirewallAPI.dll
16 FirewallAPI.dll FWEnumFirewallRules+0x231 0x7ffc62f09651 C:\Windows\System32\FirewallAPI.dll
17 FirewallAPI.dll IcfIsPortAllowed+0xb7c5 0x7ffc62f2d365 C:\Windows\System32\FirewallAPI.dll
18 FirewallAPI.dll IcfIsPortAllowed+0xba5f 0x7ffc62f2d5ff C:\Windows\System32\FirewallAPI.dll
19 ipnathlp.dll ServiceMain+0x1c2dc 0x7ffc52ee552c c:\windows\system32\ipnathlp.dll
20 ipnathlp.dll ServiceMain+0x111ff 0x7ffc52eda44f c:\windows\system32\ipnathlp.dll
21 ipnathlp.dll ServiceMain+0x10b32 0x7ffc52ed9d82 c:\windows\system32\ipnathlp.dll
22 ipnathlp.dll NatShutdownTranslator+0x2c916 0x7ffc52ec61a6 c:\windows\system32\ipnathlp.dll
23 ipnathlp.dll ServiceMain+0x42b 0x7ffc52ec967b c:\windows\system32\ipnathlp.dll
24 ipnathlp.dll ServiceMain+0x114d 0x7ffc52eca39d c:\windows\system32\ipnathlp.dll
25 ipnathlp.dll ServiceMain+0x145 0x7ffc52ec9395 c:\windows\system32\ipnathlp.dll
26 svchost.exe svchost.exe+0x284b 0x7ff663d1284b C:\WINDOWS\System32\svchost.exe
27 sechost.dll BuildSecurityDescriptorForSharingAccessEx+0x6e2 0x7ffc678d76f2 C:\WINDOWS\System32\sechost.dll
28 KERNEL32.DLL BaseThreadInitThunk+0x14 0x7ffc655c2774 C:\WINDOWS\System32\KERNEL32.DLL
29 ntdll.dll RtlUserThreadStart+0x21 0x7ffc679a0d51 C:\WINDOWS\SYSTEM32\ntdll.dll
If I look at a range of stacks captured by Process Monitor, it appears that the frame numbered 19 in that trace (the last one in ipnathlp.dll:ServiceMain) is the important one. The system never seems to get back to that frame whereas the next frame (the first one in FirewallAPI.dll:IcfIsPortAllowed) shows different addresses in different captures.
The version of ipnathlp.dll is 10.0.15063.726
The version of FirewallAPI.dll is 10.0.15063.674