Microsoft KB Archive/177748

= How To Generate and Read CRS Log Files =

Article ID: 177748

Article Last Modified on 3/11/2005

-

APPLIES TO


 * Microsoft Commercial Internet System 1.0 Service Pack 2
 * Microsoft Site Server 2.0 Standard Edition
 * Microsoft Site Server 3.0 Standard Edition

-



This article was previously published under Q177748



IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry



SUMMARY
To troubleshoot Content Replication System (CRS), you can generate and analyze log files.



Windows NT Logs
CRS always writes basic logging to the Windows NT Event Log. Below is an example of the events written to the application log during a successful replication. The timestamp and machine name have been omitted:   CRS  Information  None  15024  Summary information for replication of   project test to server ServerName: Total Scanned         :   1733 Files 257684188 Bytes Actually Sent         :      8 Files   133877 Bytes Not Sent due to match :   1599 Files 257550311 Bytes

CRS None  None    15018  Replication for project test completed sucessfully. CRS Information  None  15017  Replication for project test started by   user ServerName with flags NONE. CRS Information  None  15015  Content Replication Service started successfully. CRS Information  None  15016  Content Replication Service shutdown successfully. To save event logs, click Save As on the Log menu. If the file is large, select Event Log Files (*.EVT) as the Save As type. It is also useful to clear the Application log before doing a replication. Always verify that there are no hardware-related problems in the System log.

Generating Logs
If CRS generates an error, you will need to generate CRS log files. To do this, add the global setting FullLogging. (Note that the CRS service must be running when you modify global variables.) Three commands are needed to turn on this setting:   crs setglobal fulllogging=YES crs stop crs start This will add the registry key FullLogging with a value of YES to the Windows NT Registry. You can check this either with the command:   Crs queryglobal Or, you can add the registry value manually with Regedt32.exe.

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

To add the FullLogging value:  Start Registry Editor (Regedt32.exe). Go to the following key in the registry:

HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\CRS

 On the Edit menu, click Add Value, and then use the following entry:

Value Name: FullLogging

 Exit Registry Editor.</ol>

If you open this key and find that the value has a type of REG_UNKOWN and a hexadecimal value of 59 45 53, you mistyped the word FullLogging. There is no error checking. Any word that you type after setglobal will be added to the registry. Obviously, if the value is not correct, no log files will be generated.

Log Files
Log files will be written to the following location:

<Site Server Root>:\CRS\Logfiles

There are three different log files:

CRS.LOG

CRSSRV.LOG

WEBADMIN.LOG

Crs.log is created if you use the CRS command line interface. This file will be renamed Crs.old when CRS is stopped and restarted. Webadmin.log is only generated if you open the CRS Web Administration page. This file is kept locked by the World Wide Web Publishing Service even after CRS is stopped. Thus the only way to delete or rename the Webadmin.log file is to stop and restart the WWW service. Both of these files will give information such as this the creation of a socket. Generally these files do not contain useful information.

Crssrv.log contains the information you will need to understand any problem that has happened in a replication. The Crssrv.log has a limit of 8 MB (8,388,608 bytes). Once this limit is reached, the file will be copied to Crssrv.old. Remember that only the next time the limit is reached the OLD file will be overwritten. Thus by default you will get a maximum 16 MB of log data.

If you cannot find the error in the log or the old file then you will need to increase the amount of data being logged. To increase the limit, follow these steps: <ol> Start Registry Editor (Regedt32.exe).</li> Go to the following key in the registry:

HKEY_LOCAL_MACHINE\Software\Microsoft\CRS

</li> On the Edit menu, click Add Value, and then type the following:

Value Name: LogLimit

Data Type: REG_DWORD

Radix: Dec

Value: 25165824

</li> Exit Registry Editor.</li> Stop and restart the CRS service by using Services in Control Panel or</li></ol>

by doing either of the following at the command prompt:

Net Stop CRS

-OR-

Net Start CRS

In this example, a LogLimit value of 25165824 will produce a Crssrv.log file that will grow up to 24 MB. Then it will roll over to the Crssrv.old file. Thus you will get a total of 48 MB (24 MB+24 MB) of data.

Reading Log Files
All three log files have the same format. The file is separated into six columns: Date, Time, Type, Error Number, Thread Number, and Text Message.

The timestamp only is accurate to seconds, just like the Windows NT Event Log. The number of actions that are handled in a second make this field not useful for search purposes. It is always a good idea to synchronize the clock on the starting-point and end-point servers. You can do this with the following command:

Net time \\<machine_name> /Set

There are six types of possible log entries: <pre class="fixed_text">  DBG   = Debug INF  = Information WRN  = Warning ERR  = Error FTL  = Fatal UNK  = Unknown. Most of the events are marked DBG and the error number is zero. If the type is not DBG or INF, you will also get an Error Number.

The next field is the Thread number. This is crucial to understanding where CRS is sending the file. If multiple destinations are configured you can find the destination by looking when a thread is created. This will tell you what files are being sent.

The final field is the Text Message. This will tell you what action is taking place. If an error occurs you can see what function was called and what line of source code was executing. In some cases you can also find the return code.

Sample Log
This is an example of an error found in the CRSSRV.LOG file: <pre class="fixed_text">  11/21/97 15:55:33 WRN 10053 183 recv @E:\77fre\server\crs\crsdll\cserve.cpp 1876 First, you should notice that the type is not set to ERR. Most of the time CRS will write a Windows NT Event as an error but in the log it has the WRN type. This is what was written to the Application Log: <pre class="fixed_text">  11/21/97 3:55:33 PM CRS Error  None 15162 Waiting to abort project CRSVIEW after losing connection with source machine. Second, the error code written to the event log (in this case 15162) is different from the error number in the log (in this case 10053).

Third, you can see that thread 183 failed in the recv function, which is located in the CSERVE.CPP source file. The failure happened on line 1876.

Additional query words: replicate site server

Keywords: kbhowto kbnetwork KB177748

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.