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