In my previous Daily Drill Down on dial-up troubleshooting, I discussed how you could tell whether or not a failed dial-up session was related to a faulty phone line. However, as you’re no doubt aware, the phone line isn’t always to blame. In this article, I’ll explain some other problems that can cause a dial-up session to fail. I’ll also give you some tips on how to troubleshoot and cure such problems.

Test the modems
Once you’ve verified that your phone line is working correctly, the next step is to run a diagnostic check on the modems that are involved in the process. Running a diagnostic check on the client’s modem is relatively easy. If the client computer is running Windows 9x, you can perform a diagnostic check by selecting Settings | Control Panel from the Start menu. When Control Panel opens, double-click on the Modems icon. When you do, you’ll see the Modems Properties sheet. Then, select the properties sheet’s Diagnostic tab, and you’ll see a summary of each COM port and the device that’s connected to it. Select the COM port that’s linked to your modem and click the More Info button. After a brief delay, you’ll see a summary screen similar to the one shown in Figure A that displays the results of the various AT commands. Different types of modems will display different results. As long as you see a result screen though, it proves that Windows is able to communicate with the modem.

Figure A
If Windows is able to display a summary screen that’s similar to this one, then it is able to communicate with your modem.

Server-side modem diagnostics
If Windows passes the modem diagnostic check, the next step is to check the modem that you’re trying to dial in to. The procedure for doing this will be different depending on exactly what you’re dialing in to.

For example, if you’re dialing in to another Windows 9x machine, the procedure for diagnosing the remote modem would be the exact same as the one that you used on the client machine. If you happen to be dialing in to a Windows 2000 RAS server, on the other hand, the procedure for testing the modem is slightly different.

To test a modem on a Windows 2000 Server, open Control Panel and double-click on the Phone And Modem Options icon. Next, you’ll see the Phone And Modem Options properties sheet. Select the Modems tab, select the modem that you want to test, and click the Properties button. Doing so will display the modem’s properties sheet. Select the Diagnostics tab and click the Query Modem button. In a few seconds, you’ll see a summary screen that’s similar to the one shown in Figure A, or you’ll see an error message like the one shown in Figure B.

Figure B
If Windows is unable to communicate with the selected modem, you’ll see an error message like this one.

Testing a server’s modem is a relatively simple process. However, there are a few things that you need to consider before you can simply assume that the remote modem is okay. First, remember that if you’re dialing in to the network through a VPN connection, the server’s modem (if it even has one) is only a small piece of the puzzle. If you’re using a VPN connection, you aren’t dialing in directly to the server, you’re dialing in to the Internet (or some other network) and are then patching through to the remote network. In such a situation, the best test that you can perform is to make sure that both the client and the remote network are still able to access the Internet and that the remote network’s firewall is set to allow VPN packets to flow through.

Another potential complication occurs when you dial in directly to the remote network but the server is connected to a modem bank rather than to a single modem. There are several different types of modem banks out there. I’ve seen lots of cases in which the modem bank as a whole will be functional and will pass various diagnostic tests but a single modem out of the bank will be having problems. The best advice here is that if the client’s modem checks out okay and you suspect a modem failure, be sure to perform a check on each modem within the modem bank rather than just testing the modem bank as a whole.

Troubleshooting the basics
Now, let’s assume that you have a standard setup where the client is dialing in directly to a single modem on the server but you received an error message similar to the one shown in Figure B. What do you do to fix the problem?

If either machine fails the communications test then, the next step is to figure out why. One of the most common causes of a failed communications test is that some application previously used the modem and never released it. Perhaps the application crashed or was just poorly written. In either instance, the trick is to regain control of the modem. The easiest way to do that is to completely power down the system (including the modem if you’re using an external modem). Then, turn the modem back on (if it’s an external modem) and boot the machine. Try the test again.

If the test still fails, it’s time to go through all of the standard checks. If you’re using an external modem, verify that the modem has power and that the cable is securely installed. If you’re using a serial modem, verify that the modem is plugged into the correct COM port and that the COM port hasn’t been disabled. If you’re using a USB modem, verify that the USB cable is securely plugged in at both ends and that the system isn’t having some sort of problem with its USB port. You can test USB functionality by plugging in a different USB device or by looking at the Device Manager.

If you’re using an internal modem, turn off and unplug the computer. Then, remove and reseat the modem. Plug the computer back in, boot it up, and see if Windows detects the modem. Sometimes the vibration from the fan will jar an internal card loose.

Once you’ve verified that the cables are secure, the modem is getting power, and the modem is plugged securely into its slot, it’s time to take more drastic measures. Try removing the modem’s driver and using the Add New Hardware wizard to redetect the modem. If Windows isn’t able to detect the modem, try to remember the last time that the modem worked and recall what has changed since then. Perhaps you’ve recently installed some new hardware device that conflicts with the modem or recently installed a new application, service pack, etc. If any such change has occurred, try retracing your steps and seeing if a conflict exists between the modem and whatever change has recently occurred.

Of course, it’s always possible that the modem has simply gone bad. Phone lines are notorious for having power surges. If a surge protector doesn’t protect the phone line, then it’s possible that a power surge could have burned out the modem. The only way to really be sure is to try plugging the modem into a different PC and testing it. If the modem works in the other PC, then the modem is obviously good. Your problem lies either in a hardware conflict or in a software problem.

Get control of the COM port
Earlier I stated that the dial-up problem could be caused by some application taking control of the COM port and never releasing it. It’s possible that such a program (or driver) could be loading from within the Startup folder or could be initialized through the Registry. This is especially true if the PC’s user frequents adult Web sites. There are several pornography sites that secretly install a dialer program onto your PC when you visit their sites. Such dialer programs typically connect to a remote server at start-up. This remote server is usually connected to some 1-900 number that costs an outrageous amount of money per minute.

If you’re concerned about such rogue applications, you can check the Registry for their existence. To do so, open the Registry Editor by entering the REGEDIT command.


Remember that the Registry is pretty much the heart and soul of Windows. You can destroy Windows and/or your applications by making a mistake in editing the Registry. Therefore, always remember that the Registry Editor saves changes instantly and that you should never make a change to the Registry unless you’ve first made a full system backup and understand the full nature of the change that you’re making.

Here are the Registry locations from which a rogue application could be launched:

  • HKEY_LOCAL_MACHINE | Software | Microsoft | Windows | CurrentVersion | Run
  • HKEY_LOCAL_MACHINE | Software | Microsoft | Windows | CurrentVersion | RunOnce
  • HKEY_LOCAL_MACHINE | Software | Microsoft | Windows | CurrentVersion | RunOnceEx
  • HKEY_LOCAL_MACHINE | Software | Microsoft | Windows | CurrentVersion | RunServices
  • HKEY_LOCAL_MACHINE | Software | Microsoft | Windows | CurrentVersion | RunServicesOnce

Verify connectivity
Up to this point, I’ve assumed that either the phone lines or one of the modems has sustained a level of damage that prevents them from connecting. However, many times, the modem will be fully capable of connecting to the remote server, but things just don’t seem to work after the initial connection has been established. There are several things (beyond just noisy phone lines) that can cause this problem.

One such problem is a DHCP problem. As you might know, a DHCP server assigns IP addresses to network clients. Many times, networks are configured to assign an IP address to dial up clients through a DHCP server. The client may not be able to communicate correctly if it is configured to use a static IP address, but the server is expecting to assign the client a dynamic IP address. Even though the client may be able to communicate using the static IP address, using a different address format (such as addresses with different subnet masks) could cause the client and the server to not be able to communicate with each other.

To test to see if a client is receiving a dynamic IP address from a DHCP server, enter the command WINIPCFG at the Run prompt. When you do, you’ll see the IP Configuration dialog box. Because you aren’t dialed in to the server at the moment, the IP address should currently be Remember that if your client is connected to a network, there may be multiple adapters with various IP addresses. Therefore, make sure that you’re checking the correct one. If you have multiple adapters, the dial-up adapter will probably be listed as the PPP adapter.

Next, dial in to the remote network and try running the WINIPCFG command again to see if the adapter has been assigned an IP address. If the dial-up adapter has been assigned an address, then communications are working. If the client fails to get an IP address, you should check the server to make sure that it’s configured properly and that all of the addresses haven’t been used.

I should mention that if you’re using Windows NT Workstation or Windows 2000 Professional, the WINIPCFG command doesn’t exist. As an alternative, you’ll have to open a command prompt window and enter the IPCONFIG command.

There are many different things that can cause a dial-up session to fail, from basic connectivity issues all the way up to IP address resolution problems. By reading my first Daily Drill Down and this one, you should have an expansive set of troubleshooting techniques to use the next time someone has trouble getting connected.