Troubleshooting Tips

WebSite Pro Resources
May 6, 1998

These WebSite Pro troubleshooting guidelines are provided to help you diagnose and solve problems on your own. This is divided into several sections:

• Troubleshooting Guidelines
• Common Problems and Solutions
• Contacting Technical Support

The Troubleshooting Guidelines section describes the troubleshooting tools that come with WebSite Pro (such as the various logs and tracing options), and suggests typical places to look for the causes of problems.

Common Problems and Solutions have been collected from O’Reilly Technical Support and reflect questions users have had with previous versions of WebSite; some of these also appear in the WebSite Knowledge Base.

This document ends with Contacting Technical Support. We highly recommend that you read this document and check the online resources before calling Technical Support. Remember that 30 days of initial installation support is available free to registered users. Be sure to send in the registration card (located in the front of Volume 1: Mastering the Elements), or register online.

Many of the problems you may encounter while installing and starting your server are networking related. The specific problems can be myriad, from a mistyped IP address to an incorrectly configured TCP/IP setup. These problems are beyond the scope of this book and should be addressed with your network administrator or your Internet service provider. If you suspect the problem is with your TCP/IP configuration, see the documentation for your operating and network systems.

• Reboot the system to ensure that the effects of any unstable or faulty software are removed from memory.
• Make sure you have completed and used the WebSite Pro Installation Requirements checklist (Chapter 2 in Volume I, Mastering the Elements ) during installation.
• Make sure you have tested the server according to the procedures outlined in Chapter 3 in Volume I, Mastering the Elements.
• Run the WebSite Pro Server Self-Test to verify that your server is set up correctly. (See Chapter 3 in Volume I, Mastering the Elements.) Complete specific examples in the server self-test for areas in which you are having problems. For example, if an image map you are creating won’t work correctly, but the one in the server self-test does, compare the source code in the self-test with the code you created and find your error.
• Browse WebSite Pro from the local computer and from a different computer. If browsing locally works, but remotely doesn’t, you have a network problem. Contact your network administrator.
• Test your network connection with another tool or application, such as ping or telnet. For example, if you ping localhost, the true name it resolves to should be the same name used in Server Properties (Identity page) and in your TCP/IP configuration(computer name and host/domain name).

Server

• Stop the server and check the server log. (See Chapter 12 in Volume I, Mastering the Elements.) This is the first place to look any time you have an error.
• Also check the error log. (See Chapter 12 in Volume I, Mastering the Elements.), and the NT Event Log.
• Enable various tracing options in the Logging tab of the Server Properties sheet. Additional tracing option data will now appear in the server log. Recreate the problems you are having. Then stop the server and check the tracing data in the server log. (See Chapter 12 in Volume I, Mastering the Elements.)
• Check the WebSite Pro abort log (located in the WebSite directory) for fatal internal server errors. When the server won’t start, the abort log may show you why.
• Look closely at the error messages sent from the server to the browser. For example, in the “Not Found” return, the server reports both the URL and the physical file pathname for the URL target—information invaluable in diagnosing mapping problems. Not all browsers save error messages. If yours doesn’t, we recommend that you try another browser or enable Dump Sent Data tracing, which shows what the server sent to the browser. (See Chapter 12 in Volume I, Mastering the Elements.)
• Your web browser’s View Source option often points out useful information—perhaps an HTML tag is missing or incomplete. (See Chapter 5 in Volume I, Mastering the Elements.)

CGIs

• Double-check your mapping. Make sure that CGI mappings do not conflict with document mappings. Remember that CGI directories cannot exist within document directories. (See Chapter 9 in Volume I, Mastering the Elements.)
• If you are doing CGI work, enable CGI tracing in Logging and use the DEBUG_MODE CGI variable to enable debugging/tracing features of your CGI program. (See Chapters 7, 8, 9 and 10, in Volume II, Creating Dynamic Content for information on testing and debugging CGI programs.)

There must be a TCP/IP protocol installed on the computer acting as the server. (This is the default on Windows NT. Windows 95 requires a network card or dialup adapter to be installed.) Within the TCP/IP settings, an IP address must be assigned to the local computer. Website Pro uses this information to configure itself, allowing an intranet (LAN or sole computer) web site to function. For further information on setting up an IP address in a TCP/IP stack, please consult your operating system’s documentation or third party documentation. O’Reilly and Associates, Inc., specializes in this type of documentation, visit our site for a complete online catalog. For more information, see Installing WebSite on a Windows NT 4.0 “Stand Alone” and Installing Website on a Stand Alone Windows 95 machine in the WebSite Knowledge Base.

Server or Network

When I try to start the server, it responds with a 2140 error.

Solution

Error 2140 is a general NT error meaning the service or application did not start correctly. Look for the specific error message in the server log (C:\WebSite\logs\server.log) or abort log (C:\WebSite\abort.log). Some of the most common error messages and their solutions are listed below.

Missing Registry data for foo

Somehow the Registry has been compromised. This error is often caused by third party products. Use the Registry editor to read HKEY_LOCAL_MACHINE\SOFTWARE\Denny\WebServer\CurrentVersion. Find the area the error message refers to and try to correct the problem. Also see the WebSite Knowledge Base for articles on specific errors of this type.

Document root directory C:\foo does not exist

You have pointed the document root to a directory that does not exist. Either create the directory and move appropiate files to it or enter the correct name on the Mapping page of Server Properties.

Failed to change password on wspro_anon, code = 5

This error message occurs when you attempt to run WebSite Pro as a service in the local system account and that account doesn't have the ability to change the password on the PDC. To solve this problem, set an explicit password (8 to 14 characters) on the anonymous account being used by the server (by default, wspro_anon). Set the password first in the NT User Manager and then add it to the Anonymous Account field on the Identity page of Server Properties in this format:

wspro_anon:foobarfoo

where foobarfoo is the explicit password you set. The colon is required.

Failed to log into account wspro_anon (code 1314)

WebSite Pro needs additional privileges to run as a desktop application under your account, or as a service under any account other than Local System. You must add these privileges to the account using the NT User Manager. From the User Manager Policies menu, choose User Rights. On the User Rights dialog, check the box on the lower left corner to show advanced user rights and add the following rights to the account WebSite will run under (not this is not the wspro_anon account):

• act as part of the operating system
• create a token object
• replace a process level token

You will need to logout of your system for these to take affect.

Failed to log into account wspro_anon (code 1326)

Verify that the wspro_anon account was created in the user database (via the NT User Manager) and try setting the password explicitly as above.

Failed to log in anonymous account wspro_anon (code 1792)

You don't have the Net Logon service started and it is required for you to login to your PDC. Start Net Logon through Services in the Control Panel.

Problem

How can I edit the numbers in the page counters?

Solution

The values stored in .ctr files (SSI Page counter files) can be edited using a Hex Editor, however Roy Rabey has created a useful and easy program, SSI Count, to do this as well. Follow the link from WebSite Central to get SSI Count.

Problem

The server shows no connections when I know there are some.

Solution

Due to the speed at which WebSite responds, it will appear that the server never showed the connection. In reality, the WebSite icon didn't have enough time to display the connection.

Problem

Turning off WebSite Pro Access Logging

Solution

Go into the Logging tab in Server Properties, and remove the name of the access log file.

Problem

I'm trying to get ASP to work without having to create an NT account and log in. If I don't do that, I get a Thread Token error.

Solution

ASP, regardless of what server it is running on, requires the following:

1. It must run in the context of an impersonated native NT account.
2. It must run under an application root listed in the IIS/PWS virtual root area.

WebSite Pro addresses (1) by adding access control so that the ASP applications run with the Run in NT User Context check box enabled on the ASP tab of the Server Property sheet.

To address (2), WebSite Pro allows you to map the directory for ASP files to the virtual root area with the ASP Application Root checkbox on the Mapping tab of the Server Property sheet.

Problem

My ASP files won't run.

Solution

If your ASP files won't run, you may not have the correct access control setting for the directory. ASP files must be in, or below, a directory that has Run in NT user context set. To set Run in NT user context for a directory, go to the Access tab of the server's property sheet, add the URL path, and check the Run in NT user context box. For information on this and other access control options, see Chapter 10 in Volume I: Mastering the Elements.

Problem

Where can I find the server serial number?
How can I tell which version of the server is running?
How can I tell which version of the property sheet is installed?

Solution

Run the WebSite Version Information tool, see the WebSite program group on your Start Menu.

Problem

When using the NT command scheduler (AT or WinAT), logcycle.exe doesn’t cycle the server logs.

Solution

Logcycle.exe is a desktop application. To successfully schedule log cycling, it must be able to communicate with AT and WebSite Pro. To ensure proper communication, set up the following services:

1. Scheduler service (must be running for AT to work)—allow service to interact with desktop (control panel, services, scheduler, startup button)
2. WebSite Pro as a service—allow service to interact with desktop (control panel, services, webserver, startup button)
3. WebSite Pro as a desktop application—no special requirements
4. AT—command line needs to have the argument /interactive
5. WinAT (GUI AT interface from resource kit)—interact with desktop checked

Any time you run WinAT and edit an entry, verify that /interactive is turned on. A bug in WinAT causes /interactive to be turned off when entries are edited.

Problem

I have WebSite Pro running under Windows 95 and I want to administer it remotely. Why am I having problems?

Solution

First, you cannot remotely administer the WebSite Pro server running under Windows 95 from a computer running Windows NT. Administering the server from another Windows 95 system requires the following conditions:

• The remote computer (the one running WebSite Pro) must be on a network (in the same domain) as a Windows NT system with a user list. The NT system enables user-level security for Windows 95 administration.
• Enable remote Registry administration on the remote Windows 95 computer by installing the Remote Registry service (located on your Win95 CD-ROM), and by selecting User- Level (rather than Share-Level) security. Note also, in order to administer remotely, you must be logged into the local computer as a user who has administrator privileges on the remote computer (as defined by the user list on the NT system).

Some of my links work fine and others don’t. I suspect my problem may be mapping. Can you give me some pointers?

Solution

First, read Chapter 9 of Volume I, Mastering the Elements carefully and work through the examples. Apply the principles covered in that chapter to your own situation. In a nutshell, here are some general principles on relative URLs that generally cause the most problems in creating document links in your HTML files:

• Relative URLs are relative to the current document.
• The current document is the URL displayed by the browser when a document is loaded.
• A URL with a leading slash is different because a leading slash denotes the current server’s document root. Thus, the URL /index.html equals http://current_server/index.html
• Avoid URLs beginning in ../. These URLs can easily cause grief. Also, when writing a URL that contains a space in an HTML document name, be sure to escape the space; e.g. http://server.com/my files/ should be written as http://server.com/my%20files/

CGI

I have a server that uses only CGI programs (no static documents), and I would like to allow users to self-register. How can I get the username and password information from the authentication dialog?

Solution

To get the browser to display the username and password dialog (if the request doesn't contain a username), have your CGI program respond something like this: Send "HTTP/1.0 401 Not Authorized" Send "WWW-Authenticate:Basic Realm=""My Cool App""" This response causes the browser to display the username/password dialog. The user fills it in, presses OK, and the browser repeats the previous request with the username and password included. Your CGI application will get both username and password and if you are using CGI, they will be stored in these two variables: CGI_AuthUser and CGI_AuthPass. Note that this example is for CGI programs written in Visual Basic. If you aren't using Visual Basic, the process is still the same, except you need to know the key names for username and password that are used in the INI file. For more information on this, see the Windows CGI Specification that is shipped with WebSite Pro. If you are using the Standard CGI interface, the environment variable names are AUTH_USER and AUTH_PASSWORD.

Problem

My CGI execution is slow and my disk seems to be beaten to death.

Solution

Nothing will improve this situation better than adding more RAM. On Windows NT, 16MB is not enough to run NT, WebSite Pro, and do database CGI. In fact, the RAM requirements for WebSite Pro are 32 MB minimum for Windows NT and 16 MB minimum for Windows 95. Note that those figures are the minimums. If you have a heavy load and run complex CGI programs, or if you are running a mix of database CGI and local work on the same system, you should consider 64MB or 128MB. WebSite users universally attest to dramatically improved performance when they increase their RAM. For more on this topic, see O’Reilly Software’s Knowledge Base white paper, You Gotta Have RAM. Problem

When I set up virtual servers, all my CGI programs stop working.

Solution

Make sure your CGI directories are properly mapped for each new server. Each virtual server must have a URL prefix. Add that prefix to the mapping for each CGI. For example: /prefix/cgi-win/ C:\path\to\Win CGI directory

If you use the Identity wizard to set up your virtual servers, the document and CGI mapping is done automatically for you. See the Identity page in Server Properties and the instructions in Chapter 8 in Volume I: Mastering the Elements.

Problem

I’m having problems with a CGI program that I wrote. Any tips for debugging it?

Solution

See the white paper on Debugging CGI programs in the Tech Center at WebSite Central. Also refer to Chapters 8 and 9 in Volume II: Creating Dynamic Content.

Problem

My CGI programs work okay except that images in the resulting documents are broken.

Solution

CGI programs create virtual documents, which have no location in file space. Thus, any relative URLs (for images or links) don’t work because relative URLs are relative to the current document (see the next question for more on mapping). Note the following examples:

<img src="foo.gif">

This reference is bad because the URL path is completely relative. The server will not be able to locate this document.

<img src="/foo.gif">

This reference is better because the leading slash makes the URL path absolute to the document root of the server.

<img src="http://domain/foo.gif">

This is the best reference because the URL is complete, and it leaves no ambiguity for the image’s location.

Problem

My CGI temp directory seems to amass a lot of files.

Solution

When you run a CGI application or script, a copy of the information is stored in the CGI-TEMP directory. Under normal circumstances, these files are deleted automatically by WebSite after completion of the CGI request. If these files are not being deleted, check the Logging tab under Server Properties to see if the API/CGI Execution tracing option is selected. Selecting this option will cause the files to remain in the CGI-TEMP directory so they can be examined for the purpose of debugging and development. During normal operation the tracing options should all be unchecked.

Problem

What causes a Perl CGI to generate this message: “no blank line separating header and data”? And what can I do about it?

Solution

WebSite Pro expects CGI programs to produce valid output which it can send to the browser. If a CGI program generates an error message instead, WebSite Pro sees this simply as invalid output and sends the above “no blank line” message. Most often, this occurs when there has been an error in a Perl script. Perl writes an error message to the output, but the error message is not formatted as a valid CGI output. The Visual Basic module, cgi32.bas, that is included with WebSite Pro, is designed to format error messages so that they do appear in the browser window. The most common Perl errors are using relative pathnames in the script, which makes an assumption about the current directory or using a script that calls a UNIX service that is not duplicated in Windows, such as SendMail. To find out what actually was in the CGI output that caused the error, turn on CGI tracing in Server Properties, Logging tab. This will cause the server to leave temp files in the CGI temp directory containing information about the request and the output that the CGI program wrote. For more on this, see the white paper, Debugging CGI Programs in the WebSite Knowledge Base.

Other resources available to you are:

• WebSite Pro Resources
• WebSite-Talk, our mail list server for O’Reilly Software users

After you register your software, you have up to 30 days of free initial installation support over the telephone during our normal business hours, Monday through Friday (Holidays excluded) 7:00 am to 5:00 pm Pacific time.

Should you need assistance beyond basic installation, telephone Technical Support is available on a pay-per-incident basis. Most major credit cards are accepted for this service. Our current rate appears on the O’Reilly Software Online home page. If the incident is determined to be an O’Reilly software defect, your credit card will not be charged. Please have the following information ready when you call:

• Your O’Reilly Software Access Number for the specific software
• Current version of the software and service pack (if any)
• Your Credit Card number and expiration date
• The type of operating system
• Exact text and number of any error message that occurred
• Copy of your server log

A case number will be assigned to your incident for follow-up purposes. A simple problem may be answered while you are on the telephone. Usually we need 1 to 2 working days to respond to you with an update or answer. We will get back to you if your problem needs to go to a higher level for resolution.

Annual Technical Support subscriptions are available for specific O’Reilly Software Products. Annual subscriptions allow for limited annual telephone or email Technical Support of specific O’Reilly software products. To learn more about Annual Technical Support subscriptions, contact O’Reilly & Associates Customer Service at 1-(800)-998-9938.

Definitions of Types of Technical Support

Technical Support is available for O’Reilly Software products with the normally provided and documented configurable interfaces and properties. There is no technical support available from O’Reilly for third party software, customer-specific applications (e.g. CGI), or modifications made to O’Reilly software (e.g. HTML code). Installation support is considered successful execution of the Server Self-Test utility and initialization of Server Management tools (e.g. WebFind, WebIndex, WebView). Items such as CGI, hosting multiple identities and Certificate Authentication are not covered. Technical Support is not available for "demo" software.

Copyright © 1994-97 O'Reilly & Associates, Inc. All Rights Reserved. O'Reilly Software Online, WebSite Central, WebSite, and WebSite Professional are trademarks of O'Reilly & Associates, Inc.

All other names are the trademarks of their respective companies.