.shell (Command Shell)
The .shell command launches a shell process and redirects its output to the debugger, or to a specified file.
.shell [Options] [ShellCommand]
.shell -i InFile [-o OutFile [-e ErrFile]] [Options] ShellCommand
Parameters
InFile
Specifies the path and file name of a file to be used for input. If you intend to offer no input after the initial command, you can specify a single hyphen (-) instead of InFile, with no space before the hyphen.
OutFile
Specifies the path and file name of a file to be used for standard output. If -o **** OutFile is omitted, output is sent to the Debugger Command window. If you do not want this output displayed or saved in a file, you can specify a single hyphen (-) instead of OutFile, with no space before the hyphen.
ErrFile
Specifies the path and file name of a file to be used for error output. If -e ErrFile is omitted, error output is sent to the same place as standard output. If you do not want this output displayed or saved in a file, you can specify a single hyphen (-) instead of ErrFile, with no space before the hyphen.
Options Can be any number of the following options:
-ci "Commands"
Processes the specified debugger commands, and then passes their output as an input file to the process being launched. Commands can be any number of debugger commands, separated by semicolons, and enclosed in quotation marks.
-x
Causes any process being spawned to be completely detached from the debugger. This allows you to create processes which will continue running even after the debugging session ends.
ShellCommand
Specifies the application command line or Microsoft MS-DOS command to be executed.
Environment
| Item | Description |
|---|---|
| Modes | User mode, kernel mode |
| Targets | Live, crash dump |
| Platforms | All |
Additional Information
For other ways of accessing the command shell, see Using Shell Commands.
Remarks
The .shell command is not supported when the output of a user-mode debugger is redirected to the kernel debugger. For more information about redirecting output to the kernel debugger (sometimes called NTSD over KD), see Controlling the User-Mode Debugger from the Kernel Debugger.
The entire line after the .shell command will be interpreted as a Windows command (even if it contains a semicolon). This line should not be enclosed in quotation marks. There must be a space between .shell and the ShellCommand (additional leading spaces are ignored).
The output from the command will appear in the Debugger Command window, unless the -o **** OutFile parameter is used.
Issuing a .shell command with no parameters will activate the shell and leave it open. All subsequent commands will be interpreted as Windows commands. During this time, the debugger will display messages reading <.shell process may need input>, and the WinDbg prompt will be replaced with an Input> prompt. Sometimes, a separate Command Prompt window will appear when the debugger leaves the shell open. This window should be ignored; all input and output will be done through the Debugger Command window.
To close this shell and return to the debugger itself, type exit or .shell_quit. (The .shell_quit command is more powerful, because it works even if the shell is frozen.)
This command cannot be used while debugging CSRSS, because new processes cannot be created without CSRSS being active.
You can use the -ci flag to run one or more debugger commands and then pass their output to a shell process. For example, you could pass the output from the !process 0 7 command to a Perl script by using the following command:
0:000> .shell -ci "!process 0 7" perl.exe parsemyoutput.pl