FRS Logs

  • Article

FRS creates text-based logs in the systemroot \Debug directory to help you debug problems. The Ntfrsapi.log file contains events that take place during promotion and demotion — namely, creating the subkeys in the NTFRS registry key.

To observe a particular event, take a snapshot of the log files as close to the occurrence of the event as possible. Save the log files in a different location so they can be examined afterward.

Log Settings

The Ntfrs log files store transaction and event detail in sequentially numbered files: Ntfrs_0001 through Ntfrs_0005. Transactions and events are written to the log with the highest version number in existence at that time. The characteristics of the log files are determined by the values of several registry entries in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters subkey. After the number of logs specified by the value of the Debug Log Files registry entry have been filled, the lowest log version is deleted and the remaining log file names are decremented by n –1 to make room for a new log file.

Log detail is controlled by the value of the Debug Log Severity registry entry, ranging from 0 to 5, with 5 providing the most detail. Log size is determined by the value of the Debug Maximum Log Messages registry entry. The default value of 10,000 lines for Debug Maximum Log Messages results in a ~ 1-MB log file for a total of 10 MB of logs ( Debug Log Files * ( Debug Maximum Log Message * 100)). Setting Debug Log Messages to 50,000 results in a 5-MB log file and 25 MB of log detail with default settings.

To change the quantity, size, or level of detail of FRS log files, edit the values of the registry entries. Before you increase either the size or quantity of log files, make sure sufficient disk space is available. In general, budget 1 MB for each 10,000 messages.

caution-iconCaution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings that might degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

To change the characteristics of Ntfrs log files

  1. From the Start menu, click Run .

  2. Type cmd , and then type net stop ntfrs .

  3. Start a registry editor (either Regedit.exe or Regedt32.exe).

  4. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and edit the values of the following entries:

      • Debug Log Severity : Determines the level of detail in the Ntfrs_000n.log files. Severity levels are assigned to different debug print statements in the FRS code. If the value of this entry is 0, only the most severe events are recorded in the log. If the value of this entry is 5, almost all events are recorded in the log. Higher values are inclusive.

      • Debug Log Files : Determines how many FRS service transaction and event log files can be active simultaneously. Logs are written on a first in–first out basis with the highest number containing the most recently logged entries. Logs 1 through 5 are created in sequential order. When the number of messages written to Ntfrs_0005.log reaches the value of Debug Maximum Log Messages , Ntfrs_0001.log is deleted, Ntfrs_0002.log becomes 1, 3 becomes 2, and so on.

      • Debug Maximum Log Messages : Determines how many entries can be stored in a debug log file. 10,000 entries use approximately 1 MB of space on disk.

    These entries are not visible by default. Use the Edit menu to add them, if necessary.

  5. Close the registry editor and restart FRS. FRS creates the specified log files automatically.

To capture a random or intermittent event, you might want to expand FRS logging capability. For example, you can increase the number of log files to 50 and then archive the files when they become full. This accumulates the history needed to respond to overnight queries from users, for example.

Depending on the problem that is being investigated, it might be necessary to review logs on both the inbound and outbound replicas. System clocks must be synchronized so that events can be correlated between replication partners.

Finally, the recovery setting for the FRS service in service control manager (SCM) can be critical to locating and keeping important log events on the system. If the service is asserting but SCM is configured to automatically start FRS upon error, enough log traffic might be generated to cause events in Ntfrs_0005.log to decrement and be deleted from the drive. Stop the service on both the inbound and outbound replicas close to the time when an error occurs, and then copy the logs to a safe place.

Analyzing Log Files

The first step to solving problems with the logs is to make sure the Debug Log Severity entry in the registry is set high enough to capture the events needed to identify the problem. Severity settings range from 0 to 5 and are cumulative, meaning that a setting of 4 includes log events with a severity of 0 to 3.

Next, identify errors, warning messages, and milestone events in the log files. A good practice is to start at the bottom of the last log file and work your way up. Focus on keywords such as "install," "success," and "fail." If you do not find the error that you are looking for, start at the bottom of the previous log (Ntfrs_0005, then Ntfrs_0004, and so on). Use the find command to isolate errors in the log files as follows:

find /in " error warn fail " ntfrs.* >err.tmp

Depending on the context, some errors (such as, "jet attach db – 1811. Db not found") can be ignored because the Ntfrs.jdb file does not exist the first time FRS starts. Until the service creates the file, expect to see this immediately after Dcpromo or when you delete the Ntfrs.jdb file manually. Sharing violations, designated by the SHARING_VIOLATION status code, occur when a user or process has a lock on a file. Because FRS tracks only closed files, locked files and directories do not replicate.

If failure errors are encountered, look at the thread number and follow up all events in the log that have matching thread identifiers until you see the associated change order.

To determine why a file on Computer A has not replicated to a second or third replica, locate the ":: COG" number in the Ntfrs_00 n .log files on the originating server. Search for the same globally unique identifier (GUID) in the logs on the second and third replicas.