Troubleshooting Modem Internet Access

When you use a modem to access the internet, you are relying on several layers of software and functionality:

Each layer is generally oblivious of the layer beneath, and assumes it is on more solid ground. For example, many Internet applications behave as if they are permanently wired into the Internet, and don't consider the possibility that the modem may have hung up the connection (e.g. "Unable to resolve IP address for server")

Not only that, but some of the most misleading error messages thrown up by Windows happen here, such as "Unable to establish a common set of networking protocols", "Unable to communicate with the modem", or "Modem is in use by another dial-up connection".

So when you have to troubleshoot this lot, the most important mistake to avoid is digging in the wrong place! Changing a bunch of settings at one level when the problem lies at another will not only fail to fix the problem, but may introduce new reasons why it won't work - so when you do fix the problem, you won't realize it because it will still not work.

When you use the Internet via modem, the following things have to work:

If on the phone, try to get the user to connect directly via Dial-Up Networking, rather than as a side-effect of doing something or other within an Internet application. Questions to ask:

Can PC see the modem?

First, make sure there is no other software currently using the modem, such as fax or voice messaging utilities that run underfoot to answer the phone. Windows will report this as "the modem is in use by another dial-up connection" or bytes to that effect. Once that's excluded, read on.

It is at this point (and generally only at this point) that you have to fuss with COM: ports, IO port addresses, IRQ assignments, and the CMOS "Peripheral Setup" menu. Once you can see some sort of discourse in the modem log, or hear the modem do anything at all, you are generally past these concerns.

But before jumping in, check the obvious:

These factors don't apply to internal modems, however.

How to see the modem, if it's known to Windows

Control Panel, Modems gives you the best view of the modems that are known to the PC; use "More info..." from the Diagnostics tab to ask the modem what it is. Look for things like the modulation standards...

V.32 - 9600 bps data modulation ITU standard
V.32bis - 14400 bps data modulation ITU standard
V.34 - 28800 or 33600 bps data modulation ITU standard
V.90 - 56000 bps (PCM) data modulation ITU standard

...and fax command standards (+FCLASS)...

Class 1 - lowest denominator for fax modems
Class 2.0 - USR and other TI chipset modems
Class 2 - most other Class 2.x-capable chipsets

Almost all 'real' modems connect to the PC via a standard serial port that is either part of the PC (external serial modems) or the modem (internal hardware modems); the exceptions being those Motorola externals that use a parallel port instead. USB modems I have no experience with; can't help you there.

The rest are 'soft' modems that include almost all PCI internals and some ISA internals. These are described variously as PC-Tel, "Host Side Processing" (HSP), RPI, WinModem, "Requires Microsoft Windows" or "Requires Pentium Processor". The lack of hardware not only places the processing load on the system, but also chains you to the quality or otherwise of the "special" drivers it needs.

In some cases, "soft" modems use two layers of driver software; one for the "virtual" serial port, and one for the modem itself. Until you see the "special" serial port listed in Device Manager under "Ports (COM&LPT)", you won't find the modem. In contrast, most modern PCI modems appear in device Manager under "Other Devices" as a PCI Communication Device if they don't have their drivers installed.

Real serial port modems, be they internal or external, need no driver code at all for anything other than voice messaging; the "driver" for these is simply an .inf file that lists the AT commands and responses familiar to the modem.

Resolving IO port and IRQ issues

Serial ports use an Interrupt Request Line (IRQ) and an IO port address, and IRQ clashes are a common problem. You can see all the IRQ assignments known to Windows by viewing the Properties of "My Computer" at the top of the Device Manager list.

The standard COM: hardware resource assignments are:

COM1 - IO port 03F8 hex - IRQ 4
COM2 - IO port 02F8 hex - IRQ 3
COM3 - IO port 03E8 hex - IRQ 4
COM4 - IO port 02E8 hex - IRQ 3

Systems often have a serial mouse on COM1:, so if you add an internal modem, you can crash into this. There are three solutions to this problem:

  1. Mouse on COM1:, int modem COM3:
  2. Mouse on COM2:, int modem COM3:
  3. Mouse on COM1:, int modem COM4:, no COM3:
  4. Mouse on COM1:, int modem COM2:, disable PC's COM2:

You cannot use two COM: ports within the same Windows session if they share an IRQ, so that kills option (1) unless you use a non-standard IRQ for the modem.

On some systems, there is partial overlap between the COM4: IO address and some registers used by an old IBM post-VGA standard. Some programs (e.g. MSD) don't like "missing" COM: ports as they detect by enumeration rather than identity, so installing an internal modem as COM4: with no COM3: present can cause problems for this reason as well. That makes option (3) unattractive.

Option (4) is also unattractive, simply because it goes against the grain to disable a facility if this can be avoided!

That leaves option (2) as the way to go, though the "mouse is always on COM1:, duh" mindset often gets in the way there :-)

Which ever way you go, there's a trap to be aware of; CMOS settings. Modern systems with serial ports built into the motherboard may default to "Auto" within CMOS, and in practice, that means the serial port with the mouse attached is automatically deemed to be COM1:. Couple that with ATX case systems that use 9-pin sockets for both serial ports, and you can see the potential for things to go wrong if CMOS assignments are not strapped down, or if CMOS settings are lost. Lost CMOS settings will torpedo both methods (2) and (4).

If both RD and SD LEDs are permanently lit up...

...then you may have a particular problem that I've seen only once (and recently).  About the only thing the -12V line of the power supply is used for, is to power the RS-232 (serial port) data signal; -12V for "off", 0V for "on".  If the -12V line fails (e.g. because the blue line is pulled slightly out of the motherboard's power connector) then the modem won't respond in any OS, and the Receive Data and Send Data LEDs (or software equivalent) may be permanently on.  Recent systems that report internal power supply voltages in CMOS settings, or via a Windows utility, will show you a poor or absent -12V power voltage.

Can modem understand AT commands?

For everything except voice messaging, 'real' modems are controlled entirely by sending commands as character strings via the serial port. That's why these modems don't need "drivers" at the code level! Command strings start with the characters AT, and the modem sends back response codes in reply. The list of commands and responses are defined in an .inf file for the modem, which is usually referred to as the modem's "driver" by the same people who call the system unit the "hard drive".

If the modem does not understand an AT command, it sends the string "ERROR" as the response (or the numeric equivalent). When Windows encounters this, it throws up what is probably the most misleading error message you will ever see: "Unable to communicate with the modem". This triggers a wild goose chase involving serial port assignments, COM: ports, etc.

Using the modem log

The best way to asses this issue is to enable the modem log. In Windows 95, this is done through Dial-Up Networking, Rt-click connectoid, General tab, Configure button, Connection tab, Advanced button, and the checkbox to enable the log. It's slightly easier in Windows 98 and Millennium, though you follow the same tortuous route to get to the checkbox.

The log truncates at around 256k, so you may want to Find the existing log and rename it out of the way. In Windows 95, the log is always called ModemLog.txt, but because Windows 98 and later support "shotgun" technology (dual modem dialup) each modem has it's own log file name. Fortunately, you don't have to care about that; you can read the log through the same dialog where you enable it; that's the "slightly easier" bit I was referring to :-)

Once you have enabled the log and tried doing a dialup, you can read the log and see what it says. If it's blank (and it's been properly enabled, yadda yadda), then the chances are your problem is earlier; the PC isn't talking to the modem at all.

When you read the log, look for:

  1. The name of the .inf file used to define the modem
  2. The [section] within the .inf file that defines the modem
  3. Any ERROR response
  4. The AT command that precedes an ERROR
  5. Connection speed such as CARRIER 33600
  6. Error correction e.g. LAPM, ALT, V.42 or NONE
  7. Data compression e.g. V.42BIS, NMP or NONE
  8. Serial port overruns or framing errors

For "Unable to communicate with the modem" you are only interested in (3) and (4). For an inability to maintain a connection, or intermittent logon failure, you are interested in (6) and possibly (8).

Once you see which AT command is generating the error, you can use any program that lets you talk directly to the modem, such as Terminate or other decent "terminal" program. Enter the AT command fragments one at a time, in the form ATxxx where xxx will often start with &, \, % or + but not =. See which fragment reports ERROR, then go and hunt it down and kill it (another page yet to be written - but here's a hint; hack the modem's .inf as well as the registry), or take the easy way out; use one of the generic modem .inf for the modem instead!

Connection speed reporting

If you use a generic .inf, you will never see Windows display a true modem-to-modem connection speed, even if the modem reports this to Windows. Instead, you will see your PC-to-modem serial port speed, i.e. that set for the serial port. These are "round numbers" (if you think in base 2) such as:

9600
19200
38400
57600
115200

The carrier rate is the speed between the two modems, and is usually a more oddball number that is sometimes a multiple of an underlying 600 bps baud rate (bps higher than the baud rate is achieved by sending multiple bits per state change as one of multiple possible frequencies or wave shapes), e.g.:

12000
12800
14400
21600
26400
28800
32400
49333

If you don't see the carrier rate reported by Windows (and you are not using a generic .inf) or within the modem log, you can usually improve the reporting via an ATW command. Most modems use ATW to determine the reporting level (if not forced back to stone-age by an ATX0 setting) but they aren't consistent about the values they use, so try W0, W1 and W2 (expect an ERROR on W2 on many modems). You can enter the Wn command under Extra Settings (same dialog where you enabled the modem log); you don't need to use the AT prefix there.

Once you hear the modem attempt a dial, you are generally past the AT command hurdle.

Can modem see dial tone?

At this point we interface with the telephone system for the first time.

The user will usually hear the "brrrrrr..." unless there are factors that prevent this from ever being heard (a silent modem with no handset attached; typical in laptops if PCMCIA sound is disabled).

If the user can hear the dialtone it excludes:

If the modem cannot "see" the dialtone, i.e. won't dial, it's one of:

  1. Regionally-challenged modem doesn't understand local telco dialtone signal
  2. PABX is providing an incompatible dialtone signal
  3. Telco "voice messaging" or other value-add is providing an incompatible dialtone signal
  4. Mild lightening damage to modem

Caveat: If you swap the modem lines that go to the line wall socket and the handset, you will still hear dialtone when you pick up the handset (contrary to what you'd expect) but the modem won't work.

Best cabling practice is to take the lead from the wall line socket to the modem's "Line" socket, and then attach every other handset and device to the modem's "Phone" socket. That means no other device can interfere with the modem while it is online. This isn't possible with laptop modems and a few rather dismal desktop modems that lack a "Phone" socket.

You can force the modem to ignore dialtone either through the "front door" or by using the ATX3 command. Some regionally-challenged modems see the telco's dialtone as "Busy" and will immediately report "busy" if they get dialtone; then you'd have to use ATX1 if ATX2 doesn't work. If adding explicit AT commands via "Extra Settings", leave out the AT and place them after any Z or &W commands ;-)

Some PABXs require a digit to be dialed for an outside line, and others require a non-dial button to be pressed. The latter are impossible to emulate via the modem, and you can give up now. The former may work if you define the digit, followed by a comma, as to be dialed for an outside line (e.g. via Telephony settings). The comma causes the dial to pause at that point, in case the PABX is slow to give the real dialtone (which the modem won't wait for if dialtone detection is disabled). Else the first digit of the ISP's number may be lost, if dialed directly after the prefix.

Generally, it's best to avoid modem connections via PABX. Ignore that advice if you like, but brace yourself for frustration if you do!

Can modem dial?

If you hear the modem dialing, but you still hear the dialtone in the background, then it's one of:

Does the modem dial the right number?

First, make sure the phone number being dialed is the right number, and not:

Next, make sure there's no incorrect city code or dial prefix (PABX etc.)

Next, try a comma between any city code, prefix etc. to pause the dialing so that the next link can get ready to accept the dial. This is particularly important if you are suppressing dialtone detection; in such cases, try a comma before the first digit to be dialed (e.g. ,0,21,1025 for "PABX","Cape Town", "ISP")

Finally; listen to the dialing itself. I've seen a spate of modems fail during a 5-week period when out telco was converting from 6-digit numbers to 7-digit (digital exchange) numbers; and they all failed the same way; inability to dial out, or they would dial the wrong number, and you could hear the pulse runs were either "broken" or incorrect for the digits being dialed. I suspect line-side damage from "testing" in these cases; mild lightening damage may present in the same way.

Does anything answer on the other side?

Our telco uses three different "busy" signals (as heard thru the handset):

The last of these plagued a local ISP for months until they opened up new lines that didn't go through that particular exchange. It's the sort of problem that only the telco may be able to fix.

You may hear a tiny (and usually indignant) voice if the number dialed is a voice number. If the little voice sounds quite tranquil, it's probably a recorded message to the effect that "This number has been changed". Either way, it's a good idea to voice call the number to see what is going on.

You may also hear fax probe tone (a constant-pitch, repeating beeeeep) if the number dialed was (or is now) a fax number.

It may be that you don't hear anything, because the particular modem doesn't pass any sound through the system or modem speaker. In which case, voice dial the number via the hand set and see if you hear telco indicators, voices, fax tone or a modem.

Do modems handshake for data comms?

This is the noisy bit that should go silent and follow on to "Verifying user name and password", i.e. the Internet logon process. This is where inter-modem compatibility issues usually apply, though bad line and serial port overrun issues can apply too.

Turning on the sound

It's helpful to be able to listen to this process, but not via a handset connected "in front" of the modem (as "the observer will affect the experiment"). There are front-door settings to enable the modem speaker, or you can use L3M1 via "Extra Settings". On a laptop, PCMCIA sound may be disabled elsewhere under PCMCIA setup, so check there too.

Interpreting what you hear

V.34 (and earlier) connection negotiation sounds like bursts of white noise; usually two of these before connect; they sound different, as if generated by first one modem, then the other.

Bad signs are where you hear the constant-pitch drone of one modem through the white noise of the other; this usually means the line conditions are so bad that the "listening" modem has lost the plot and given up. A three-tone series of constant pitch, of pattern booooo beeeeee baaaaaaaaaaa... is particularly dismal, implying the "listening" modem is not responding at all.

Another alarming sound is like a death-rattle ("klaklaklaklak...") that will have you lunging for the power switch when you first hear it. It indicates some derangement of the handshaking process, possibly such that the modem needs to be reset afterwards, but I've yet to see it do any permanent harm. I've heard it about four times, and from client's descriptions, perhaps know of another two.

If this phase is successful and the modems have common ground, they may attempt a PCM ("56k") handshake. 56Flex and 56Flex-derived V.90 sounds like a snaaarrrlll, whereas X2 and X2-derived V.90 sounds like two resonant bongs.

On a good line, PCM will work and the modems will go silent at that point. On a not-so-good line (or an OK line that has more than one analog segment) you will either not hear a PCM attempt, or you will hear another V.34 negotiation session afterwards as the modems fall back from PCM to older modulation methods.

You can look at the modem log to see exactly what the modems did and what initial carrier rate they attained - noting that the modems may immediately re-train and drop to a slower speed. Some illustrious modem brands are famed for that, so if you are doing performance testing, you need to time point-to-point data transfers, or at least break in via +++ and check the in-session carrier rate that way before going back online via ATO; command.

ISP-crippled modems

If you find the modem hangs up immediately after the handshake, then you are probably dealing with an ISP-crippled modem. These have the firmware altered to look for a particular string as part of the handshake process; if they don't see it, they disconnect (why else would a string like "ISP xxxx says Have A Nice Day" be immediately followed by a severe copyright notice? <grin>).

Apart from preventing data comms with other computers (so no PC Anywhere, direct-dial BBSs, EDI services or other ISPs), this may also nuke the fax functionality of the modem. For all that, these ISP-crippled modems are a good value as nearly-free Internet appliances, as they are generally full-hardware external modems that don't slow the processor down or require "special" drivers. Assuming they are nearly-free, of course - and that you know the limitations before you buy.

If you have got this far, you are generally past inter-modem issues unless failure to attain error correction leads to line drops and intermittent logon failures.

Can computers establish TCP/IP?

Once the modems pass the hurdle of establishing a connection, the computers try to establish networking. The Internet is rooted in UNIX and uses a protocol called TCP/IP. For this to work, TCP/IP must be installed and be bound to the Dial-Up Adapter, but you can also get "Unable to negotiate a set of network protocols" errors if you have NetBEUI and IPX bound to the Dial-Up Adapter as well. By default, Win95 will bind all three protocols to a newly-created DUN connectoid, so it is up to the user to unbind IPX and NetBEUI for connectoids that are to be used to access the Internet.

You may also have problems if the ISP uses SLIP rather than PPP to log in to the Internet - but this should be really unusual in the 21st century!

Can computer log on to the Internet?

If the modems connect but you cannot log into the Internet, there may be one of several causes:

  1. Wrong ISP (i.e. you dial some other ISP's phone number)
  2. Wrong logon ID
  3. Wrong logon password
  4. ISP uses caller ID, and you have this feature disabled
  5. The modems did not establish error correction
  6. The ISP's account expired, is not paid up, or is not yet active

Usually one assumes (3), but (2) is just as effective in preventing access and is quite common where the logon ID is not the same as the first part of the email address, or is the entire email address. Cause (4) does not apply in South Africa but may apply elsewhere.

Cause (5) should be suspected if login failure is intermittent, and if successful logins often fail with spontaneous disconnects. Without error correction, line noise is interpreted as spurious data, causing extra or mangled characters to become embedded in the logon prompt, user ID, and password as these are sent between the two systems, causing failure to recognize this data. Enable and examine the modem log file to see whether error correction is achieved; look for LAPM, V.42 or ALT report strings.

There may be ISP-side issues, especially if the number you are using is a new one that may not have access to the full user database as yet, or an old number that has been pensioned off. An ISP that grows by acquisition may also change from using the first part of the email address as the login ID, to using the entire address, or a different ID altogether. This is usually to prevent same-name ambiguities where two user databases are merged into one after an ISP buys out another.

Do modems maintain the connection?

Connects that are dropped after seconds to minutes, or variably fail the logon process, may be due to bad line issues but also failure to establish error correction. Use the modem log to see what is going on, checking for LAPM, V.42 or ALT error correction and serial port overruns.

Another common cause is interference from other telco devices in the house, if these are connected "in front" of the modem - e.g. a burglar alarm that "calls to base" daily to confirm it is operational, other handsets on extensions of the same line that are being picked up, and so on.

Finally, if the PABX or telco is using a "call waiting" service, this will cause disconnects when the "you have a call waiting" signal breaks into the connection. There may be a dial prefix you can use that will disable this feature for the length of the current call; if so, use this within the DUN connectoid's settings, e.g. in the "dial this to get an outside line" field.

Can computer see servers by name?

A happy connection that can't find anything usually implies a failure of DNS, but can be caused by other issues, e.g.:

Whereas DNS failure affects the ability to locate any server by name (including mail and news servers), the other failures listed above may affect only one particular Internet service such as http ("the web"). In addition, DNS failure can be bypassed by the use of direct IP addressing, whereas your mileage will vary with the other scenarios. IP addressing does bypass MTX's censorship of access to the antivirus sites that it screens, but will probably not bypass a mis-configured firewall.

Generally, an early debugging step would be to bypass any web proxy services until everything else is working fine. Like defragging a file system, proxy service is a cherry-on-top performance booster that shouldn't be used when underlying stability is in question. But unlike defrag, using a proxy service when things are not working properly will not roast your data :-)

DNS

TCP/IP uses globally unique 4-byte identifiers conventionally represented as xxx.xxx.xxx.xxx (where xxx is a non-padded decimal between 0 and 255) to address everything that is addressable, including your PC while you are connected.

These are called Internet Protocol (IP) addresses. Your ISP owns a range of these, and will typically assign you one chosen at random from this range ("pick a card, any card"). This gives you a certain degree on anonymity from hackers, compared to always-connected, constant-IP connections such as DSL, cable modems, etc.

Other computers are generally referenced by domain names (e.g. not.a.real.domain.name.com) rather than naked IP addresses. Not only is this easier for humans to manage, but it also allows these names to be re-routed to different IP addresses should the need arise.

But there is always one server that cannot be referenced other than IP address; the Domain Name Server that performs the task of translating the domain name you want to the IP address the computer needs. Depending on your ISP, you may need to specify a primary and secondary (fall-back) DNS server IP address via connectoid Rt-click, Properties, Server Types, TCP/IP Settings. Some ISPs only use a primary DNS address, others assign the DNS of the day automatically when you connect.

Some rather untogether ISPs assign the DNS addresses via "active content" that runs from their home page, so that if you suppress active content, change the home page, or don't happen to use http during the session (e.g. you just do mail, news, ftp or whatever) then you can't find anything. Suspect this scenario if the ISP's software setup uses an oddball dialer or a raw IP address for the web browser's home page.

You can also screen for other possible ISP issues by using Zone Alarm or similar to block any incoming port access. If you find that your ability to locate servers by name evaporates when you do this, it suggests the ISP is relying on port access to your system as part of the mechanism of DNS setup on a per-session basis. This is theory only; I've never seen it in practice, but I'd suspect this if DNS falls over around the same time that Zone Alarm was installed :-)

Dueling Winsocks

Winsock ("Windows Sockets") is what allows multiple applications to share access to a single modem simultaneously; along with RNAapp.exe, this forms the "glue" of dial-up networking. There are two Winsock dlls; Winsock.dll that handles access for 16-bit applications, and WSock32.dll that handles 32-bit applications.

Native Windows 9x does the work in WSock32.dll, whereas the original "32-bit" Trumpet Winsock does the work in Winsock.dll; in either case, the other .dll thunks calls across to the one that actually does the work. But these Winsocks can get mangled in various ways:

Many online service providers supply their own Winsock; something of a necessity in the "duh, what is 'Winsock' and 'the Internet'?" days of Windows 3.yuk, but counter-productive in the Windows 9x era.

Can computer send mail?

Sending of mail is usually done through Simple Mail Transfer Protocol, which sends mail without identifying the sender via a logon process. This has led to abuse by spammers (junk mailers) who bog down "open" mail relays by posting huge wads of bulk mail through them.

ISPs have fought back in one of two ways; by checking the IP address against those that are owned by the ISP, or by sending mail only after a successful mail retrieval or at least a POP login. The first will cause sending of mail to fail if you dial into the Internet through a different ISP, and the second will fail if your email program tries to send mail before it checks for incoming mail.

Read this page if you need to connect to the Internet through one ISP and use another ISP for email, e.g. if you are running two ISP accounts, are travelling, etc.

But the most common cause of isolated failure to send mail is an incorrect smtp server name within the settings of the email application. Suspect this if a newly-setup account has never been able to send mail, but also if an existing account loses this ability. It may be that the account is using a raw IP address that no longer matches the smtp server, or is using an old server name that is no longer aliased to the real server name by the ISP.

Can computer get mail?

Retrieval of mail is usually done through Post Office Protocol, which identifies the user via a logon process. Sometimes the same ID and password is used that was used to log onto the Internet, but not always; the two are separate processes and it is only by convention that the same data is used for both. If your ISP uses another ISP to "back end" the service, or has itself been taken over by another ISP, then it is quite common to have different ID and password for the Internet and POP logon processes.

Although you usually have to send mail through the same ISP that you use to log onto the Internet, you can only get your mail from the ISP that hosts that email address. Read this page if you need to connect to the Internet through one ISP and access your email from another ISP, e.g. if you are running two ISP accounts, are travelling, etc.

After incorrect ID and password, the most common cause of isolated failure to get mail is an incorrect pop server name within the settings of the email application. Suspect this if a newly-setup account has never been able to get mail, but also if an existing account loses this ability. It may be that the account is using a raw IP address that no longer matches the pop server, or is using an old server name that is no longer aliased to the real server name by the ISP.

Check also that the payment status of the ISP account is known to be valid by the ISP. Some ISPs will curtail access to email while still allowing connection to the Internet, when an account is considered to be in arrears.

Can computer read news?

Usenet news is carried by the NNTP service, and if this does not work then you are probably using the wrong name for the NNTP server. The name is often, but not always, news.isp.com (where 'isp.com' is the domain name of your Internet Service Provider).

Often the name of the news server reveals who is really providing your raw Internet service, where one "front" ISP is back-ended by another larger one. For this reason, South Africans connecting via a small ISP often have success with news.saix.net as the news server name.

Can computers disconnect?

Windows 95 will sometimes lock up when disconnecting from the Internet. Sometimes this is caused by an AT command that sets the modem to wait indefinitely before concluding that the line has been dropped, but more often the cause is the use of WINS.

If you have this problem, try disabling WINS within the properties of TCP/IP on DUN (via Network Properties), but don't do this if you are accessing the Internet via Internet Connection Sharing in Win98SE or later, and be careful if you are on a LAN that uses TCP/IP.

Do strange things happen online?

If strange things happen at a particular web site, try the site with active content completely disabled - you may be victim to buggy or malicious scripting within the web page.

If strange things happen when online, but irrespective of what you are doing at the time, then do a formal virus check and check the startup axis for signs of a RAT (Remote Access Trojan), and consider the use of Zone Alarm or similar to wall out incoming hack attacks. 

It may be appropriate to check for a trojanized WSock32.dll even if a formal virus scan is negative.  First, extract a fresh WSock32.dll from your CD, then Rt-click this and the active file to check the Version tab for version consistency.  Then you can use the DOS FC /B command to compare the two files; if they differ, rename the old one away and copy in the new one.  Like most anti-malware tasks, these steps are best done in DOS mode (other than the initial version check).

By "strange things", I mean: Lockups, crashes, BSoDs, files appearing or disappearing, CD-ROM trays opening, mouse pointer being moved around, random characters being inserted while you type, and so forth. Less obvious issues would be unexpected credit card billings or replies to newsgroup postings you never made, both indicative of identity theft.

 

(C) Chris Quirke, all rights reserved - February 2001, updated May 2001

Back to index