Finally I’m writing about this command. I love it! It’s so powerful! .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
According to the WinDbg help, options can be:
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.
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.
The way I use it is:
.shell –i – -ci “command” FIND “string”
Why is that? I use it to extract specific information from a command.
The FIND command is not part of .shell. It’s a DOS command. Remember, .shell gives you access to the shell.
Searches for a text string in a file or files.
FIND [/V] [/C] [/N] [/I] “string” [[drive:][path]filename[ …]]
Displays all lines NOT containing the specified string.
Displays only the count of lines containing the string.
Displays line numbers with the displayed lines.
Ignores the case of characters when searching for the string.
Specifies the text string to find.
Specifies a file or files to search.
If a pathname is not specified, FIND searches the text typed at the prompt or piped from another command.
So the combination of .shell and FIND is very powerful and it’s the most common way to use this command.
Example #1 – Searching for a specific managed object:
.shell –i – -ci “!dso” FIND “Sherlock.FoundBlocking”
Example #2 – Searching for a specific mnemonic from the disassembled code:
.shell –i – -ci “uf USER32!InternalCallWinProc” FIND “cmp”
Example #3 – Dumping part of the raw call stack and searching for USER32 calls:
.shell –i – -ci “dps @$csp L300” FIND “USER32”