I recently encountered a serious problem in
my Windows Vista 64-Bit Edition machine.
Suddenly and for no apparent reason, I
couldn’t open any Web pages because
Microsoft Internet Explorer (IE) repeatedly
failed to connect to Web sites. (Although
Vista x64 comes with both the 32-bit and
64-bit versions of IE by default, Vista x64
opens the 32-bit version because most of
the plug-ins fail to run or even install in the
64-bit version.) After some investigation,
I discovered that some of my other 32-bit
programs couldn’t connect to the Internet
or any network. Also, the 32-bit programs
were crashing when I tried to close them.
Curiously, the 64-bit programs didn’t experience
these problems. I could open, close,
and use them to connect to the Internet
and networks.
I knew that TCP/IP wasn’t causing the
problem because my machine could ping
hosts and resolve DNS names. The event
logs didn’t contain any relevant entries,
except for those noting that the 32-bit applications
crashed.
I tried restoring the system and repairing
the network connection, but the
problem remained. Vista SP1 Release Candidate
1 (RC1) had been made public the day
before, so I gave it a try. Nothing changed.
At this point, I seriously considered
reinstalling Vista but instead decided to
use the ISO Open Systems Interconnection
(OSI) model to troubleshoot the problem
and find a solution. (If you’re unfamiliar
with the OSI model or you need to refresh
your memory, go to the Microsoft article
“The OSI Model’s Seven Layers Defined and
Functions Explained” at support.microsoft.com/kb/103884.)
Because every 32-bit application was
experiencing problems, it wasn’t application
specific, so I eliminated the application
layer. The problem didn’t seem to have any
relationship with conversion or encryption,
so I also
eliminated the
presentation
layer.
I then had
to deal with
the session
layer. I opened
a 32-bit Telnet
client and
tried to open a
session with a server. The program failed to
connect without even creating any network
traffic. (No packets were being transmitted
or received on the NIC’s properties. I
even used a sniffer to double-check this.)
I wondered whether there was a way to
repair just the session layer in Windows.
After I rejected the idea of trying to find
the relevant DLLs and replacing them with
DLLs from the Vista DVD, I remembered an
old tool that I hadn’t tried: Netsh.
While doing some Internet research on
Netsh, I found the Microsoft article “How to
determine and to recover from Winsock2
corruption in Windows Server 2003, in
Windows XP, and in Windows Vista”
(support.microsoft.com/kb/811259). This
article presented a solution that made
sense: Use Netsh to reset the Windows
socket layer.
Using Netsh for this purpose is easy. You
just need to open a command prompt, start
the Netsh program, then type winsock reset.
Alternatively, you can abbreviate winsock to
wins so that you’re typing wins reset. You have
to reboot for the changes to take effect.
I like Netsh and have used it many times
throughout the years. However, I didn’t
realize you can use it to repair the Windows
socket layer because I never faced that problem
before. Now I have one more reason to
like Netsh: It fixed the problem and saved me
from the always painful reinstallation.
—Apostolos Fotakelis, systems administrator, NATO,
and freelance IT consultant