[Editor's Note: Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to Karen Bemowski at kbemowski@winntmag.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.]
For an unknown reason, TCP/IP commands on my Windows NT server were taking a long time to execute. For example, ping 127.0.0.1 took from 70 seconds to 100 seconds to get going.
I tried shutting down as many system components as possible, but it made no difference. I tried reinstalling TCP/IP and then the network adapter, but to no avail. I then installed both Service Pack 3 (SP3) and the Roll-Up hotfix, with no improvement in performance. At that point, I began wondering whether Internet Explorer (IE) 4.0 was causing the problem. I decided to investigate, although I wasn't too hopeful because I had installed IE 4.0 on other servers and they weren't experiencing the problem.
In my investigation, I first used the Dependency Walker utility (depends.exe) from the Microsoft Windows NT Server 4.0 Resource Kit to get a list of .dll files that ping uses. I then used the resource kit's File and Directory Comparison utility (windiff.exe) to compare the System32 directory contents of the server in question with the System32 directory contents of another server that ran IE 4.0 but didn't have the problem. I filtered the Comparison utility's output to show only those .dll files that were different. Finally, I produced a list of .dll files that were common to the outputs of both utilities. The list of .dll files that were common to both utilities contained only three .dll files.
One at a time, I ran the three .dll files from the normal server on a second installation of NT (always a good idea, especially if you can install the software on a different controller, drive, or partition). By comparing the results of these tests with the results of the Dependency Walker utility, I tracked the offending file: wsock32.dll. The tests identified the normal server's .dll file as 4.00 and the slow server's .dll file as 1.0. The 1.0 .dll file was rws32.dll in disguise and claimed to be part of Proxy Server. I don't know how this .dll file got on the server.
My experience has taught me an important lesson: If you have a resource kit, take the time to find out what's in it. In the long run, this time investment will pay off.
—David Barnes
dave@foursys.co.uk
Another Way to Connect to a Network Resource
Shawn Bayern's tip "Poor Man's SU Utility" (Reader to Reader, July 1998) describes how you can use the NET USE command to connect to a network resource. However, this approach is useful only for tasks that require file access. Another approach is to connect to a remote machine's IPC$ share as an administrative user. This approach gives you administrative permissions so that you can remotely perform tasks, such as editing the Registry or using Server Manager.
For example, after I removed software from a client PC, the PC didn't display the desktop after I logged back on. I couldn't do anything locally on the machine to fix the problem because the GUI was inaccessible. So from another desktop, I connected to the PC's IPC$ share with an administrator account, then used regedt32 to remove the fault service entry. After I rebooted, the PC worked fine.
—Troy Bruder
troy.bruder@aptconsulting.com