$<, $><, $$<, $$><, $$ >a< (Run Script File)
The $<, $><, $$<, $$><, and $$>a< commands read the contents of the specified script file and use its contents as debugger command input.
$<Filename
$><Filename
$$<Filename
$$><Filename
$$>a<Filename [arg1 arg2 arg3 ...]
Parameters
Filename Specifies a file that contains valid debugger command text. The file name must follow Microsoft Windows file name conventions. The file name may contain spaces.
argn
Specifies any number of string arguments for the debugger to pass to the script. The debugger will replace any string of the form ${$argn} in the script file with the corresponding argn before executing the script. Arguments may not contain quotation marks or semicolons. Multiple arguments must be separated by spaces; if an argument contains a space it must be enclosed in quotation marks. All arguments are optional.
Environment
Item | Description |
---|---|
Modes | User mode, kernel mode |
Targets | Live, crash dump |
Platforms | All |
Remarks
The $$< and $< tokens execute the commands that are found in the script file literally. However, with $< you can specify any file name, including one that contains semicolons. Because $< allows semicolons to be used in the file name, you cannot concatenate $< with other debugger commands, because a semicolon cannot be used both as a command separator and as part of a file name.
The $$>< and $>< tokens execute the commands that are found in the script file literally, which means they open the script file, replace all carriage returns with semicolons, and execute the resulting text as a single command block. As with $< discussed previously, the $>< variation permits file names that contains semicolons, which means you cannot concatenate $>< with other debugger commands.
The $$>< and $>< tokens are useful if you are running scripts that contain debugger command programs. For more information about these programs, see Using Debugger Command Programs.
Unless you have file names that contain semicolons, you do not need to use either $< or $><.
The $$>a< token allows the debugger to pass arguments to the script. If Filename contains spaces, it must be enclosed in quotation marks. If too many arguments are supplied, the excess arguments are ignored. If too few arguments are supplied, any token in the source file of the form ${$argn} where n is larger than the number of supplied arguments will remain in its literal form and will not be replaced with anything. You can follow this command with a semicolon and additional commands; the presence of a semicolon terminates the argument list.
When the debugger executes a script file, the commands and their output are displayed in the Debugger Command window. When the end of the script file is reached, control returns to the debugger.
The following table summarizes how you can use these tokens.
Token | Allows file names that contain semicolons | Allows concatenation of additional commands separated by semicolons | Condenses to single command block | Allows script arguments |
---|---|---|---|---|
$< |
Yes |
No |
No |
No |
$>< |
Yes |
No |
Yes |
No |
$$< |
No |
Yes |
No |
No |
$$>< |
No |
Yes |
Yes |
No |
$$>a< |
No |
Yes |
Yes |
Yes |
The $<, $><, $$<, and $$>< commands echo the commands contained in the script file and display the output of these commands. The $$>a< command does not echo the commands found in the script file, but merely displays their output.
Script files can be nested. If the debugger encounters one of these tokens in a script file, execution moves to the new script file and returns to the previous location when the new script file has been completed. Scripts can also be called recursively.
In WinDbg, you can paste the additional command text in the Debugger Command window.
Examples
The following example demonstrates how to pass arguments to a script file, Myfile.txt. Assume that the file contains the following text:
.echo The first argument is ${$arg1}.
.echo The second argument is ${$arg2}.
Then you can pass arguments to this file by using a command like this:
0:000> $$>a<myfile.txt myFirstArg mySecondArg
The result of this command would be:
The first argument is myFirstArg.
The second argument is mySecondArg.
Here is an example of what happens when the wrong number of argument is supplied. Assume that the file My Script.txt contains the following text:
.echo The first argument is ${$arg1}.
.echo The fifth argument is ${$arg5}.
.echo The fourth argument is ${$arg4}.
Then the following semicolon-delimited command line produces output thus:
0:000> $$>a< "c:\binl\my script.txt" "First one" Two "Three More" Four; recx
The first argument is First one.
The fifth argument is ${$arg5}.
The fourth argument is Four.
ecx=0021f4ac
In the preceding example, the file name is enclosed in quotation marks because it contains a space, and arguments that contain spaces are enclosed in quotation marks as well. Although a fifth argument seems to be expected by the script, the semicolon terminates the $$>a< command after the fourth argument.