Share via

3.1.7 Other Local Events

  • Article

When a system or application error occurs, if the CER client is configured to use the Corporate Error Reporting Version 1.0 Protocol as specified in section 3.1.1, the CER client MUST perform the following actions:

  1. The CER client MUST first construct the required file paths depending on the type of error event, as specified in section 2.2.3. The CER client MUST then check for the existence of the relevant policy.txt and status.txt files, as specified in sections 2.2.4 and 2.2.5, and if they exist then read the files by using the SMB Protocol specified in [MS-SMB]. It MUST verify that the files conform to the format specified in sections 2.2.4 and 2.2.5. If the files do not conform to the specified formats, or if individual entries in those files do not conform to the specified formats, the configuration options which are incorrectly specified MUST NOT be honored by the CER client.

  2. If both a status.txt file and a policy.txt file exist for a particular error and contain the same parameter with different values, the CER client MUST use status.txt parameter over the policy.txt parameter. If neither exist, the CER client SHOULD refer to its default value for that particular parameter. <8>

  3. The CER client MUST determine whether there are already a sufficient number of reports for this particular error. First, it must determine how many reports have already been made. If the count.txt file as specified in section 2.2.1 exists, the CER client MUST read the number of copied error reporting files from it. Otherwise the CER client MUST assume that the number of reports is zero. Next, the CER client MUST determine the maximum number of copied error reporting files for this error. It first checks for a CrashesPerBucket value set by status.txt, then by policy.txt, then falls back to its default value. Finally, the CER client compares these two numbers and as long as there are fewer copied reports than the CrashesPerBucket value instructs, then the CER client MUST continue the error reporting file generation process. If there are already a sufficient number of reports then the CER client MUST skip to step 8 below.

  4. The CER client MUST check the status.txt file (section 2.2.5) for the existence of an iData parameter with an affirmative Boolean value to verify that an error reporting file is requested. If the parameter is absent or has a negative Boolean value, the CER client MUST skip to step 8 below.

  5. The CER client MUST check the status.txt file (section 2.2.5) to determine whether any additional data is specified for the error reporting file. If so, the CER client MUST collect as much of the requested data as possible (for example, if a file is requested in the GetFile section of status.txt that is not present on the system, then the file cannot be included but the error report SHOULD still be made<9>). The method of data collection is implementation-specific.<10> Note that there is no requirement that two clients use the same method or format of error information.

  6. The CER client MUST compress the complete report information into a single file by using any implementation-specific file compression.<11> Note that there is no requirement that two clients use the same file compression scheme. If the data cannot be compressed, the CER client MUST NOT continue creating an error reporting file, and MUST skip to step 8 below.

  7. The CER client MUST attempt to copy the error report to the CER file share. If this attempt fails, the error report MUST NOT be copied.

  8. If the count.txt file does not exist, the CER client MUST create the file and set its contents as follows. The value <cFilesCopied> is "1" if the CER successfully copied a file in step 7, and is otherwise "0".

     Cabs Gathered=<cFilesCopied>
 Total Hits=1
 

    If the count.txt file already exists, the CER client MUST attempt to increment the Total Hits value by one and the Cabs Gathered value by <cFilesCopied>.

  9. This final step applies only if the policy.txt or status.txt file indicated that internal tracking is enabled. If crash.log does not yet exist, the CER client MUST create an empty crash.log file at that location. Then the CER client MUST attempt to append to the crash.log file following the format specified in section 2.2.2.2. If hits.log does not yet exist, the CER client MUST create an empty hits.log file at that location. Then the CER client MUST attempt to append to the hits.log file following the format specified in section 2.2.2.1.