Errors, Parse Errors, and Warnings

During the execution of a command, Log Parser can encounter three different types of run time errors: Errors, Parse Errors, and Warnings.

Errors

Errors are exceptional events occurring during the execution of a command that cause the command to abort.

Even though Errors can occur due to a large number of reasons, the most common causes can be categorized as follows:

Invalid query syntax: the query specified in the command is invalid.

Input Format errors: the specified Input Format has encountered an error that prevents it from generating input records. This could happen, for example, when the FROM clause specifies an entity (e.g. a file) that does not exist.

Output Format errors: the specified Output Format has encountered an error that prevents it from consuming output records. This could happen, for example, when the INTO clause specifies an entity (e.g. a file) that cannot be written to.

Too many Parse Errors: the specified Input Format has encountered too many Parse Errors, as specified by the "-e" command-line global parameter.
Catastrophic errors: for example, Log Parser ran out of memory.

When an error occurs, the Log Parser command-line executable aborts the query execution and returns the error message and the error code. When an error occurs while using the Log Parser scriptable COM components, a COM exception is thrown containing the error message and the error code.
In most cases, the error code returned is the internal system error code that caused the error.

Parse Errors

Parse Errors are errors that occur while the selected Input Format generates the data on which the query operates.
Most of the times, as the name suggests, these errors are generated when a log has malformed entries (for example, when using the IISW3C Input Format), or when a system error prevents an Input Format from processing a specific entry in the data (for example, an "access denied" error on a file when using the FS Input Format).
In any event, the presence of a Parse Error indicates that the Input Format had to skip the data entry that caused the error; for example, when a Parse Error is encountered by the IISW3C Input Format while parsing a malformed line in the log, that line will be skipped and it will not be processed by the SQL engine.

Parse Errors do not generally cause early termination of the currently executing command, but rather, they are collected internally by the SQL engine and reported when the command execution is complete.
This behavior can be controlled with the -e command-line global parameter. The value used with this parameter specifies a maximum number of Parse Errors to collect internally before aborting the execution of the command.
For example, if we execute a query on an IISW3C log file specifying "-e:10", Log Parser will collect up to 10 Parse Errors during the execution of the command. If the IISW3C Input Format encounters 10 or less Parse Errors, the command will complete succesfully, and the collected Parse Errors will be reported in detail at the end of the execution. On the other hand, if the input log file contains more than 10 malformed log lines, the 11^th Parse Error will cause the command to abort and return an Error.

The default value for this command-line parameter is -1, which is a special value causing the SQL engine to ignore all Parse Errors and report only the total number of Parse Errors encountered during the execution of a command.

As an example, consider the following command, which parses an IISW3C log file and writes all the input records to a CSV file:

C:\>LogParser -i:IISW3C -o:CSV "SELECT * INTO Output.csv FROM ex020528.log"

Let's assume that the "ex020528.log" log file contains 3 malformed log lines.
After executing the command above, the output will be as follows:

Task completed with parse errors.
Parse errors:
3 parse errors occurred during processing

Statistics:
-----------
Elements processed: 997
Elements output:	997
Execution time:	 0.03 seconds

This output tells us that the command executed succesfully, but 3 Parse Errors have been encountered while processing the input data. Since the default value for the "-e" command-line parameter is -1, the SQL engine has ignored all these Parse Errors, keeping just their total count.

If we wanted these Parse Errors to be reported in detail, we could specify a value for the "-e" parameter different than -1:

C:\>LogParser -i:IISW3C -o:CSV "SELECT * INTO Output.csv FROM ex020528.log" -e:10

In this case, the output would be:

Task completed with parse errors.
Parse errors:
Error while parsing field sc-status: Error parsing StatusCode "2b00": Extra
  character(s) found in integer
  LogFile "C:\Logs\ex020528.log", Row number 23, Value "2b00"
Cannot find end-of-line - extra characters detected at the end of log entry
  LogFile "C:\Logs\ex020528.log", Row number 118
Log row terminates unexpectedly
  LogFile "C:\Logs\ex020528.log", Row number 188

Statistics:
-----------
Elements processed: 997
Elements output:	997
Execution time:	 0.03 seconds

The command still executed succesfully, and this time the 3 Parse Errors have been collected and reported at the end of the execution.

If we had specified "2" for the "-e" parameter, the SQL engine would have aborted the execution of the command, and an Error would be returned:

Task aborted.
Too many parse errors - aborting
Parse errors:
Error while parsing field sc-status: Error parsing StatusCode "2b00": Extra
  character(s) found in integer
  LogFile "C:\Logs\ex020528.log", Row number 23, Value "2b00"
Cannot find end-of-line - extra characters detected at the end of log entry
  LogFile "C:\Logs\ex020528.log", Row number 118
Log row terminates unexpectedly
  LogFile "C:\Logs\ex020528.log", Row number 188

Statistics:
-----------
Elements processed: 182
Elements output:	181
Execution time:	 0.01 seconds

Warnings

Warnings are exceptional events occurring during the execution of a command that require attention from the user.
There are only a few situations that could cause a warning, and these are handled differently depending on whether or not the warning arises during the execution of a command, or when the execution has completed.

When a warning is generated during the execution of a command, the command-line executable shows an interactive prompt to the user asking whether or not the execution should continue.

As an example, consider a command that writes output records to a CSV file.
The CSV Output Format "fileMode" parameter can be used to specify what action should be taken in case the output file already exists. The value "2" specifies that already existing output files should not be overwritten; when using this option, the CSV Output Format will raise a Warning when an already existing output file will not be overwritten:

C:\>LogParser -i:EVT -o:CSV "SELECT TOP 5 Message INTO Output.csv FROM System" -fileMode:2

WARNING: File C:\LogSamples\Output.csv exists and it will not be overwritten.
Do you want to continue? [Yes/No/Ignore all] :

When this prompt appears, the user can choose between continuing the execution of the command allowing additional warnings to trigger the prompt again, aborting the execution of the command (in which case the command terminates with an Error), or continuing the execution of the command ignoring additional warnings.

The interactive prompt can be controlled with the global -iw command-line parameter. This ON/OFF parameter specifies whether or not warnings should be ignored; the default value is "OFF", meaning that run time warnings will not be ignored and will trigger the interactive prompt. Specifying "ON", on the other hand, disables the interactive prompt, and run time warnings will be ignored and their total count will be reported when the command execution has completed:

C:\>LogParser -i:EVT -o:CSV "SELECT TOP 5 Message INTO Output.csv FROM System" -fileMode:2 -iw:ON

Task completed with warnings.
Warnings:
1 warning occurred during processing

Statistics:
-----------
Elements processed: 5
Elements output:	5
Execution time:	 0.03 seconds

Tip: If you use the Log Parser command-line executable in a non-interactive script (e.g. in a script that has been scheduled to run automatically at specific times), you should always use "ON" for the "iw" parameter, otherwise in the event of a run time warning the Log Parser command will stall waiting for a user to press a key in the interactive prompt.

Warnings that are generated when a command has completed are simply reported to the user.

For example, the "ignoreDspchErrs" parameter of the SYSLOG Output Format can be used to specify whether or not errors occurring while dispatching output records should be ignored and reported as warnings at the end of the execution.
The following example command uses the SYSLOG Output Format to send output records to a non-existing user:

C:\>LogParser -i:EVT -o:SYSLOG "SELECT TOP 5 Message INTO NonExistingUser FROM System" -ignoreDspchErrs:ON

Since the specified user does not exist, the SYSLOG Output Format will encounter an error for each output record it will try to send to the user; the "ON" value for the "ignoreDspchErrs" tells the output format to ignore these errors and report all of them when the execution has completed:

Task completed with warnings.
Warnings:
The following dispatch errors occurred:
  The message alias could not be found on the network. (5 times)

Statistics:
-----------
Elements processed: 5
Elements output:	5
Execution time:	 0.02 seconds