Video Screencast Help

CSP Command Line Arguments - Matching and Troubleshooting

Created: 27 Jun 2013 • Updated: 27 Feb 2015
Language Translations
Chuck Edson's picture
+3 3 Votes
Login to vote

In Symantec Critical System Protection, you can use command line arguments to assign executables to their own Custom Process Sets and to activate certain rules or exceptions. 

This purpose of this document is to lay out the command line matching process, the syntax of the wildcards, and how to troubleshoot an apparent mismatch in the argument.

The command line matching process is fairly straightforward; the IPS driver reads arguments as they are passed and attempts to match them with argument statements that are entered into a process binding rule or policy rule.  The driver breaks apart the argument into pattern tokens by parsing for spaces.  For instance, the argument:

                //d srrstr.dll,ExecuteScheduledSPPCreation

Will be parsed and broken into the following two pattern tokens,



Wildcards can be used.  There are two wildcards, the asterisk and the question mark.

The asterisk (*) has two uses.  When it is used without any spaces around it, it will match one or more characters in the argument. For instance,

                //d srrstr.dll,*

Will match

                //d srrstr.dll,ExecuteScheduledSPPCreation

And in another example,

                //d srrstr.dll,*xecuteScheduledSPPCreation


                //d srrstr.dll,ExecuteScheduledSPPCreation

The asterisk, when used with spaces, means that one or more pattern tokens of the argument are wildcarded.  For instance:

                * srrstr.dll,ExecuteScheduledSPPCreation

Will match

                //d srrstr.dll,ExecuteScheduledSPPCreation       

The question mark (?) is another wildcard.  Its purpose is to wildcard a single character.  This is useful for arguments that have certain patterns to match.  For instance,


Will match


Case Sensitivity

Arguments, in both Windows and -ix clients, are case sensitive by default.  File paths are not case sensitive in Windows, and are case sensitive in –ix clients.

You can use the case insensitivity switch &ci; to turn off case sensitivity.  Use &cs; to turn on case sensitivity. A space must be placed between the case sensitivity switch and the argument for it to be registered by the driver.   For example,

&ci; //d srrstr.dll,executescheduledsppcreation &cs; /V


//d srrstr.dll,ExecuteScheduledSPPCreation /V

Escape Characters

There are two escape characters, \ for Windows and / for –ix based agents.

The reason to use an escape character is because the driver will remove the leading \ or / from the argument when parsing it.  If you need the \ or / then add another slash. This is especially handy when calling cmd.exe /c.   For instance the argument:

        cmd /c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

Needs to be entered in the arguments section in the CSP policy as

        cmd //c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”


Use single quotation marks when there is a space in the argument, to prevent the driver from parsing it incorrectly

For instance, if the argument was entered like this in the policy, the driver would think that C:\Program is one token and Files\Symantec\Critical was another, and so on:

         cmd /c C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat

The correct way to enter this argument in the policy is:

        cmd //c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

When a batch file is launched in Windows, the OS adds a double quote at the beginning of any parts of arguments that have a space, and a quote-space-quote at the end of the argument.  The CSP driver recognizes this, and will treat these as single quotes.  For instance, this is what the driver will see from the OS:

      cmd /c ““C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat” “

However, when parsed, the driver will treat the argument as this:

      cmd /c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

Troubleshooting Command Line Matching Issues

Sometimes, a match is not found, so the process does not get assigned to the correct PSET.  When looking over the Command Line matches, it appears that it should match, but for some reason, the driver does not agree.

The first thing to do is to look for a uppercase/lower case mismatch.  This is the #1 cause of mismatches.

After confirming that case is not an issue, then start wildcarding parts of the argument, or all of it, and get a match.  Then add the specific arguments back in the argument string one at a time until you locate the mismatch.

The cmdmatchv2.exe tool can be used from the command line to see how the driver is parsing the information.  

Here is a screenshot of the tool.  This shows you how both the pattern entered into the policy and the command line arguments are parsed, and then gives you the output of the matching logic. 


Using this tool can help you figure out where an asterisk or question mark may need to be placed to get an argument to match.

You can get the tool from the downloads section of Connect here