Is it just me or is stuff resurfacing from the past like an IT apocalypse ? Recently an issue with hidden devices came to the fore where this problem existed over 10 years ago. So it was a bit of a surprise when so quickly after that I was confronted with another “Back to the future” challenge.
The background – a windows 7 machine being updated to windows 10. Due to a hardware conflict a rollback was required. On reboot into Windows 7 no remote access, no browser access to internet but ability to ping. The local drive share c$ was accessible remotely when tested.
Digging deeper – the PC could ping internally, across VPN WAN connections and to internet external IP addresses by number. However trying to use FQDN addresses failed as did nslookup. So its starting to look like an issue with the TCPIP stack.
Historically there have been occasions where this kind of problem had come up for me but generally they had an external cause. Malware and third party packages especially relating to network communication applications spring to mind.
At this point it was decided to check if a reset of the TCPIP stack might help which ironically I found I had partially described in a previous article (12 years ago) which was around issues where ping was behaving erratically!
Initially an attempt to reset the stack was run in a DOS session
netsh int ip reset
However on reboot it was necessary to set the IP address settings and DNS back to the static values it had previously as no dhcp address was available on the remote site. Testing at this stage showed the same failures as above but with the ability to ping local and remote address.
After some consideration an alternative reset method was discussed and the next step was to run this is a dos session
netsh winsock reset
On reboot everything sprang back into life – remote access, browsing and nslookup all working.
Despite having using this command on occasion – generally with good results. It is remarkably hard to find out what specifically this does. Microsoft’s own documentation on netsh does not really give the deep level of detail that explains what steps it takes to fix problems detected.
In retrospect it might have been useful to check the winsock catalog by running
netsh winsock show catalog
to see if any of the providers state indicated a problem
netsh /? gives a list of the options that are available and netsh winsock /? gives specifics for the winsock context.
The command used above – netsh winsock reset – according to its help does the following
Resets Winsock Catalog to a clean state.
All Winsock Layered Service Providers which were previously installed must be reinstalled
This command does not affect Winsock Name Space Provider entries
So my hunch is that the re-installation phase of this is what actually repairs the issue.