My single most used gdb command is l followed by n followed by l -.
How can I get the same in lldb?
I am not satisfied with having to type some line number just to see the code somewhere. I want to see where I am in the code, after dumping a ton of variables out to the terminal. And I used to use l - to go back to look at where I am, since subsequent calls to l will scroll me down (lldb also does this, but crucially does not respond to l -).
Perhaps I am missing something and there is some sort of "mode" i can put it in, which will show the corresponding source location in a separate buffer all the time. That would be nice, but I'm not even asking for that.
In Xcode 4.6, lldb's l alias is a simple shortcut for source list.
In the top of tree sources, this has been improved to behave more like gdb. If you look at source/Interpreter/CommandInterpreter.cpp over at http://lldb.llvm.org/ you'll see that l is now a regular expression command alias with these cases:
if (list_regex_cmd_ap->AddRegexCommand("^([0-9]+)[[:space:]]*$", "source list --line %1") &&
list_regex_cmd_ap->AddRegexCommand("^(.*[^[:space:]])[[:space:]]*:[[:space:]]*([[:digit:]]+)[[:space:]]*$", "source list --file '%1' --line %2") &&
list_regex_cmd_ap->AddRegexCommand("^\\*?(0x[[:xdigit:]]+)[[:space:]]*$", "source list --address %1") &&
list_regex_cmd_ap->AddRegexCommand("^-[[:space:]]*$", "source list --reverse") &&
list_regex_cmd_ap->AddRegexCommand("^-([[:digit:]]+)[[:space:]]*$", "source list --reverse --count %1") &&
list_regex_cmd_ap->AddRegexCommand("^(.+)$", "source list --name \"%1\"") &&
list_regex_cmd_ap->AddRegexCommand("^$", "source list"))
With these cases, you will get behavior like this:
Show current frame:
(lldb) f
#0: 0x0000000100000f2b a.out`main + 27 at a.c:15
12
13
14
-> 15 puts ("hi"); // line 15
16
17 puts ("hi"); // line 17
18 }
show previous ten lines:
(lldb) l -
5
6
7
8
9 puts ("hi"); // line 9
10
11
You can also use the stop-line-count-after and stop-line-count-before settings to control how much source context is displayed at frame stops.
Note that you can create your own regular expression command alias in your ~/.lldbinit file with the same behavior as the top-of-tree lldb's l. See help command regex for the syntax and an example.
LLDB: [How to] List source code
ie: For anyone looking for "How do I make lldb show which line I am on again? (since my recent commands have covered it up)", it is simply f. Type f to see where you are at in the code again.
f
OR
frame select
Source: LLDB: List source code
See also the help menu in lldb:
help f
shows the following:
(lldb) help f
Select the current stack frame by index from within the current thread (see
'thread backtrace'.)
Syntax: f <cmd-options> [<frame-index>]
Command Options Usage:
f [-r <offset>] [<frame-index>]
-r <offset> ( --relative <offset> )
A relative frame index offset from the current frame index.
This command takes options and free-form arguments. If your arguments resemble option
specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of
the command options and the beginning of the arguments.
'f' is an abbreviation for 'frame select'
The bottom of that help menu shows that "f is an abbreviation for frame select".
Note that in gdb, the equivalent command is simply:
f
OR
frame
user#hostname> lldb -o "image lookup -rvn file" -o "quit" "Name of exec-file" | grep "CompileUnit"
user#hostname> lldb -o "image lookup -rvs file" -o "quit" "Name of exec-file" | grep "CompileUnit"
Related
How can I repeatedly run a command in LLDB for debugging C++ code?
For example, when I set a breakpoint inside a loop and want to continue for 10 iterations before stopping, I am currently typing continue ten times manually to do this. Is there a better way?
As an example, let's say I have this code block:
int i = 0;
while (true) {
// Increment i
i++;
}
If I set a breakpoint on the line with the comment, I could keep using the command continue to go through one iteration of the loop and go back to that line. However, if I wanted to skip over 10 iterations (i.e. use the command continue 10 times), how would I do that?
lldb tends to use options where gdb would use a command argument. That makes it easier to have a bunch of different ways to condition a particular command without having to come up with ad hoc mini-syntaxes for each command.
Anyway, so in lldb you would do:
(lldb) c -i 10
You can see this in help:
(lldb) help continue
Continue execution of all threads in the current process.
Syntax: continue <cmd-options>
Command Options Usage:
continue [-i <unsigned-integer>]
-i <unsigned-integer> ( --ignore-count <unsigned-integer> )
Ignore <N> crossings of the breakpoint (if it exists) for the currently selected thread.
'continue' is an abbreviation for 'process continue'
Note also that you can do the same thing just by setting the ignore count in the breakpoint you just hit: break modify -i 10 <BKPTNO>.
Just add a conditional breakpoint. In gdb it's like this
break ... if cond
Set a breakpoint with condition cond; evaluate the expression cond each time the breakpoint is reached, and stop only if the value is nonzero--that is, if cond evaluates as true. `...' stands for one of the possible arguments described above (or no argument) specifying where to break. See section Break conditions, for more information on breakpoint conditions.
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_28.html
For example if i is currently 0 and you want to break on line 10 then use
break 10 if i >= 10
Just increase the condition value based no the current value of i
I don't know lldb but according the the mapping list break foo if strcmp(y,"hello") == 0 in gdb can be done as the following in lldb
(lldb) breakpoint set --name foo --condition '(int)strcmp(y,"hello") == 0'
(lldb) br s -n foo -c '(int)strcmp(y,"hello") == 0'
If there's no loop counter you can just declare a debug variable yourself
expr unsigned int $foo = 1
breakpoint set --name foo --condition '++$foo >= 10'
I am trying to automate some debug by printing inputs and outputs of a function via GDB, when that function hits. To enable setting breakpoints at these places, I am doing the following.
I am working with templates, and rbreak :. does not hit the breakpoints at the functions in my file. So i extract line numbers of functions from the executable as follows.
With the executable, extract the linenumber of start of a function;
nm a.out | grep "className" | grep "functionName" | grep " t " | addr2line -e a.out -f | grep "cpp" | uniq
-> this outputs the filename:linenumber
add these contents to a .gdb file with a "b prefix"
Query - how can we extract the line number of a end of a function from the executable ?
With this info, I can add it to the GDB script, the final script would
look something like below. this script would be loaded into GDB before
the execution of the program.
b filepath:<startline of function>
commands
print input1 input2 etc
continue
end
b filepath:<endline of function>
commands
print output1 output2 etc
continue
end
It remains to find only the end line of a given function belonging to a class/file, given the executable and start line of the function
I also considered using GDBs finish command but the control is back to the caller already.
it would be easy to have the prints within the called function instead of the caller, so that we can monitor input/outputs of every call of the function.
This will simplify my debug to a large extent.
Any suggestion/comments is highly appreciated.
Thanks a lot in advance !!
First, notice that template functions are not functions, but actually recipes. When you use a template the compiler generates a function from the template.
If you want to use the break command then you need the full function name. For instance, the template below
template <typename T>
inline T doubleInput(const T& x) {
return 2 * x;
}
will become the function doubleInput<int> when you pass an int, doubleInput<double> when you pass a double, etc. You need the whole name including the <type> part to add a breakpoint with the break command and even in that case it will only stop in that particular case of the template.
But the rbreak command does work with templates. If you write in gdb rbreak doubleInput* then a breakpoint will be added in all existing specializations of the template.
See the answer in this question.
I don't know if gdb nowadays has the feature to add a breakpoint in the return of a function, but answers in the nine years old question provide some possibilities, including a custom python command to find and add a breakpoint to the retq instructions or using reverse debugging. I haven't tried these options.
Taking the example from http://shanekirk.com/2017/08/gdb-tips-and-tricks-2-setting-breakpoints-with-regular-expressions/ - when I use rbreak, I get something like:
(gdb) rb TestFixture.h:.
Breakpoint 1 at 0x4008b6: file TestFixture.h, line 5.
void TestFixture::setUp();
Breakpoint 2 at 0x4008d4: file TestFixture.h, line 6.
void TestFixture::tearDown();
Breakpoint 3 at 0x4008f2: file TestFixture.h, line 7.
void TestFixture::testA();
Breakpoint 4 at 0x400910: file TestFixture.h, line 8.
void TestFixture::testB();
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004008b6 in TestFixture::setUp() at TestFixture.h:5
2 breakpoint keep y 0x00000000004008d4 in TestFixture::tearDown() at TestFixture.h:6
3 breakpoint keep y 0x00000000004008f2 in TestFixture::testA() at TestFixture.h:7
4 breakpoint keep y 0x0000000000400910 in TestFixture::testB() at TestFixture.h:8
Now, what I want is basically a dprintf-like behavior: once one of this breakpoints is hit, I just want the function name printed out, and then continue (basically, a function call trace)
However, the way I understand gdb - in order to do that, I would issue a rbreak [regex] first, then I get a bunch of breakpoints, then for each and every one of those I'd had to type manually:
commands [number-of-breakpoint]
print "[name of function]"
continue
end
... which quickly becomes a chore, especially if you end up with a lot more breakpoints than the 4 in the above example (say hundreds).
Now, it would be rather cool, if I could use something like "regex dprintf", or rdprintf, as in:
rdprintf TestFixture.h:., "%s\n", $__breakname__
... but as far as I know, there is no such command...
Or, if after issuing a rbreak TestFixture.h:., I could target the commands for those breakpoints as:
commands 1-4
print $__breakname__
continue
end
... but again, I think this does not exist either...
So is there a way to use gdb to provide this kind of a function call trace printout - without me manually typing the names of breakpoints and their commands, similar to how rbreak allows you to set multiple breakpoints with one command?
EDIT: just found List of all function calls made in an application - record function-call-history /ilc might be interesting, but there doesn't seem to be a way to limit the scope of what functions to trace, say with a regex...
Ok, via the link above, found https://stackoverflow.com/a/39124320/277826 - turns out, you can issue command for multiple breakpoints, as found by rbreak; and to print the name of the function, just use backtrace 1:
(gdb) command 1-36
Type commands for breakpoint(s) 1-36, one per line.
End with a line saying just "end".
>silent
>bt 1
>continue
>end
(gdb) r
... or with python, printing the frame at bt 0 and its parent's frame name:
command 1-36
silent
python print("{} <- {}".format( gdb.execute("bt 0", False, True).strip(), gdb.newest_frame().older().name() ))
continue
end
... or even better, python printing bt 0 function name and args, and parent name:
command 1-36
silent
python nf = gdb.newest_frame(); nfb = nf.block()
python nfargs = [ "{}={}".format(sym, nf.read_var(sym, nfb)) for sym in nfb if sym.is_argument ]
python print("#0 {}({}) <- {}".format(nf.name(), ",".join(nfargs), nf.older().name() ))
continue
end
... which would print something like:
#0 Searcher::FlagFromCmd(this=0x7fffffffaed8,cmd=808) <- FindLiveStrip::GrabToggles
#0 Searcher::FlagFromCmd(this=0x7fffffffaed8,cmd=807) <- FindLiveStrip::ToggleChanged
... and this seems to work fine; though if there are other options, I'd love to know about them.
I'd like to use the SiblimeREPL package with Sublime Text. When I try to start a REPL, I get
SublimeREPL: obtaining sane environment failed in getenv()
Check console and 'getenv_command' setting
WARN: Falling back to SublimeText environment
This happens regardless of which REPL I try to start. (I tried Ruby, Python, and Clojure.) I tried Sublime Text 2 and Sublime Text 3 with the same results. This is on Mac OS X, if that matters.
I looked in the package settings, where I see
"getenv_command": ["/bin/bash", "--login", "-c", "env"],
If I run "/bin/bash --login -c env" at a Terminal prompt, I get my environment listed.
What do I need to change in order to get a successful getenv_command?
I had the same problem as ssgam. The problem line for me is in the getenv method. It calls subprocess.check_output(getenv_command), which doesn't exist in python 2.6, which ST2 seems to use.
The trick is, it only calls subprocess.check_output() if getenv_command is truthy, and defaults to os.environ.copy() otherwise. So to get ssgam's fix without modifying the SublimeREPL package, in Preferences > Package Settings > SublimeREPL > Settings - User, do something like this:
{
"getenv_command": false
}
I investigated this issue a little bit deeper and it seems SublimeText 3 is also affected. In my case the problem is related to bash-completion feature, in particular COMP_WORDBREAKS environment variable.
Use the following command to show the contents of COMP_WORDBREAKS:
$ echo "$COMP_WORDBREAKS"
will output
"'><=;|&(:
You can also use:
$ echo $COMP_WORDBREAKS
but note that with the second command (without quotes), you'll not see that
the variable also contains a line feed character.
The problem here is the line feed character which breaks output parsing in getenv_command feature. If you extract part of the source code for SublimeREPL you can get real error message from python interpreter.
Traceback (most recent call last):
File "main.py", line 71, in getenv
env = dict(line.split('=', 1) for line in lines)
ValueError: dictionary update sequence element #6 has length 1; 2 is required
You can match element #6 with the position of COMP_WORDBREAKS in env listing.
Solution (first that came to my mind)
I can't tell at the moment what is real impact on bash-completion feature after following solution is applied and of course SublimeREPL hopefully should be fixed accordingly. Please comment my answer to fill in missing knowledge.
We may want to remove disturbing characters to get rid of the error.
First let's identify those characters
$ echo -n "${COMP_WORDBREAKS}" | od -t x1c
will output
0000000 20 09 0a 22 27 3e 3c 3b 7c 26 28 3a
\t \n " ' > < ; | & ( :
0000014
so we have three to remove. The simplest way is to add to your .bashrc following line:
COMP_WORDBREAKS="${COMP_WORDBREAKS#???}"
Voila! No more error message.
My final thought is about removed characters. I'm not fully in how bash-completion works and I'm aware of that modifying COMP_WORDBREAKS can affect other scripts using it. For now you can always change it ad-hoc.
I hope this helped.
Cheers
Found it. Fixed it. SublimeREPL assumes that running getenv_command will produce SOLELY the output from running env, and every line will contain an equals sign. But my .bash_profile echos some stuff to stdout.
The solution was to wrap my .bash_profile output in a
if [[ $- == *i* ]]
to not produce extra output besides the executed command.
TLDR;
Replace:
env = dict(line.split('=', 1) for line in lines)
in ~/.config/sublime-text-3/Packages/SublimeREPL/repls/subprocess_repl.py with
env = dict(line.split('=', 1) for line in lines if '=' in line)
(Thanks #MichaelOhlrogge for the shorter syntax)
Why this works
#develucas's solution helped me solve my issue. I didn't have the problem he was describing, but his investigation helped.
In my case, the login shell had a greeting. So, bash --login -c env (the command specified in SublimeREPL.sublime-settings file under the getenv_command option) was printing something like this:
Hello, parth!
USER=parth
SHELL=/bin/bash
.
.
.
It turns out that SublimeREPL uses the output of this command to load the environment variables - as mentioned in the comment above the getenv_command setting:
// On POSIX system SublimeText launched from GUI does not inherit
// a proper environment. Often leading to problems with finding interpreters
// or not using the ones affected by changes in ~/.profile / *rc files
// This command is used as a workaround, it's launched before any subprocess
// repl starts and it's output is parsed as an environment
"getenv_command": ["/bin/bash", "--login", "-c", "env"],
The code that parses this output is like this (in the ~/.config/sublime-text-3/Packages/SublimeREPL/repls/subprocess_repl.py file for ST3):
def getenv(self, settings):
"""Tries to get most appropriate environent, on windows
it's os.environ.copy, but on other system's we'll
try get values from login shell"""
getenv_command = settings.get("getenv_command")
if getenv_command and POSIX:
try:
output = subprocess.check_output(getenv_command)
lines = output.decode("utf-8", errors="replace").splitlines()
env = dict(line.split('=', 1) for line in lines)
return env
except:
import traceback
traceback.print_exc()
error_message(
"SublimeREPL: obtaining sane environment failed in getenv()\n"
"Check console and 'getenv_command' setting \n"
"WARN: Falling back to SublimeText environment")
# Fallback to environ.copy() if not on POSIX or sane getenv failed
return os.environ.copy()
The env = dict(line.split('=', 1) for line in lines) line causes an issue, because the first line in the bash --login -c env output has no =. So I modified this line to ignore the lines that don't have an = sign:
env = dict(line.split('=', 1) for line in lines if '=' in line)
And this solved the issue for me. Don't forget the restart Sublime Text after modifying this file.
changing COMP_WORDBREAKS does not work for me ...
i'm using ST2, and the exception was thrown at check_output().
also, name completions at the command line fails, after changing COMP_WORDBREAKS.
in my case, i changed subprocess_repl.py's env() method:
[wind]$ diff subprocess_repl.py.20151117.173317 subprocess_repl.py
160c160,161
< updated_env = env if env else self.getenv(settings)
---
> # updated_env = env if env else self.getenv(settings)
> updated_env = env if env else os.environ.copy()
[wind]$
would be interesting to find out why the problem started appearing suddenly ...
hth,cheers,
sam
The answer from #develucas mostly works for me with ST3 with OSX El Capitan except I had to put
export COMP_WORDBREAKS="${COMP_WORDBREAKS#???}"
Note the export. However, if I do this, tab completion no longer works.
I had the same problem, it was my .bash_profile that had some utility outputs, such as a welcome message etc.
These outputs are parsed by SublimeREPL to try to extract environment variables from the output of the env command, and the extraneous text lines mixed together provoked the error.
(I'd like to make a PR to SublimeREPL to try to make that phase more robust, it should not depend on particular .bash_profile implementations!)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I have come to realize that Windbg is a very powerful debugger for the Windows platform & I learn something new about it once in a while. Can fellow Windbg users share some of their mad skills?
ps: I am not looking for a nifty command, those can be found in the documentation. How about sharing tips on doing something that one couldn't otherwise imagine could be done with windbg? e.g. Some way to generate statistics about memory allocations when a process is run under windbg.
My favorite is the command .cmdtree <file> (undocumented, but referenced in previous release notes). This can assist in bringing up another window (that can be docked) to display helpful or commonly used commands. This can help make the user much more productive using the tool.
Initially talked about here, with an example for the <file> parameter:
http://blogs.msdn.com/debuggingtoolbox/archive/2008/09/17/special-command-execute-commands-from-a-customized-user-interface-with-cmdtree.aspx
Example:
alt text http://blogs.msdn.com/photos/debuggingtoolbox/images/8954736/original.aspx
To investigate a memory leak in a crash dump (since I prefer by far UMDH for live processes).
The strategy is that objects of the same type are all allocated with the same size.
Feed the !heap -h 0 command to WinDbg's command line version cdb.exe (for greater speed) to get all heap allocations:
"C:\Program Files\Debugging Tools for Windows\cdb.exe" -c "!heap -h 0;q" -z [DumpPath] > DumpHeapEntries.log
Use Cygwin to grep the list of allocations, grouping them by size:
grep "busy ([[:alnum:]]\+)" DumpHeapEntries.log \
| gawk '{ str = $8; gsub(/\(|\)/, "", str); print "0x" str " 0x" $4 }' \
| sort \
| uniq -c \
| gawk '{ printf "%10.2f %10d %10d ( %s = %d )\n", $1*strtonum($3)/1024, $1, strtonum($3), $2, strtonum($2) }' \
| sort > DumpHeapEntriesStats.log
You get a table that looks like this, for example, telling us that 25529270 allocations of 0x24 bytes take nearly 1.2 GB of memory.
8489.52 707 12296 ( 0x3000 = 12288 )
11894.28 5924 2056 ( 0x800 = 2048 )
13222.66 846250 16 ( 0x2 = 2 )
14120.41 602471 24 ( 0x2 = 2 )
31539.30 2018515 16 ( 0x1 = 1 )
38902.01 1659819 24 ( 0x1 = 1 )
40856.38 817 51208 ( 0xc800 = 51200 )
1196684.53 25529270 48 ( 0x24 = 36 )
Then if your objects have vtables, just use the dps command to seek some of the 0x24 bytes heap allocations in DumpHeapEntries.log to know the type of the objects that are taking all the memory.
0:075> dps 3be7f7e8
3be7f7e8 00020006
3be7f7ec 090c01e7
3be7f7f0 0b40fe94 SomeDll!SomeType::`vftable'
3be7f7f4 00000000
3be7f7f8 00000000
It's cheesy but it works :)
The following command comes very handy when looking on the stack for C++ objects with vtables, especially when working with release builds when quite a few things get optimized away.
dpp esp Range
Being able to load an arbitrary PE file as dump is neat:
windbg -z mylib.dll
Query GetLastError() with:
!gle
This helps to decode common error codes:
!error error_number
Almost 60% of the commands I use everyday..
dv /i /t
?? this
kM (kinda undocumented) generates links to frames
.frame x
!analyze -v
!lmi
~
Explanation
dv /i /t [doc]
dv - display names and values of local variables in the current scope
/i - specify the kind of variable: local, global, parameter, function, or unknown
/t - display data type of variables
?? this [doc]
?? - evaluate C++ expression
this - C++ this pointer
kM [doc]
k - display stack back trace
M - DML mode. Frame numbers are hyperlinks to the particular frame. For more info about kM refer to http://windbg.info/doc/1-common-cmds.html
.frame x [doc]
Switch to frame number x. 0 being the frame at top of stack, 1 being frame 1 below the 0th frame, and so on.
To display local variables from another frame on the stack, first switch to that frame - .frame x, then use dv /i /t. By default d will show info from top frame.
!analyze -v [doc1] [doc2 - Using the !analyze Extension]
!analyze - analyze extension. Display information about the current exception or bug check. Note that to run an extension we prefix !.
-v - verbose output
!lmi [doc]
!lmi - lmi extension. Display detailed information about a module.
~ [doc]
~ - Displays status for the specified thread or for all threads in the current process.
The "tip" I use most often is one that will save you from having to touch that pesky mouse so often: Alt + 1
Alt + 1 will place focus into the command window so that you can actually type a command and so that up-arrow actually scrolls through command history. However, it doesn't work if your focus is already in the scrollable command history.
Peeve: why the heck are key presses ignored while the focus is in a source window? It's not like you can edit the source code from inside WinDbg. Alt + 1 to the rescue.
One word (well, OK, three) : DML, i.e. Debugger Markup Language.
This is a fairly recent addition to WinDbg, and it's not documented in the help file. There is however some documentation in "dml.doc" in the installation directory for the Debugging Tools for Windows.
Basically, this is an HTML-like syntax you can add to your debugger scripts for formatting and, more importantly, linking. You can use links to call other scripts, or even the same script.
My day-to-day work involves maintenance on a meta-modeler that provides generic objects and relationship between objects for a large piece of C++ software. At first, to ease debugging, I had written a simple dump script that extracts relevant information from these objects.
Now, with DML, I've been able to add links to the output, allowing the same script to be called again on related objects. This allows for much faster exploration of a model.
Here's a simplified example. Assume the object under introspection has a relationship called "reference" to another object.
r #$t0 = $arg1 $$ arg1 is the address of an object to examine
$$ dump some information from $t0
$$ allow the user to examine our reference
aS /x myref ##(&((<C++ type of the reference>*)#$t0)->reference )
.block { .printf /D "<link cmd=\"$$>a< <full path to this script> ${myref}\">dump Ref</link> " }
Obviously, this a pretty canned example, but this stuff is really invaluable for me. Instead of hunting around in very complex objects for the right data members (which usually took up to a minute and various casting and dereferencing trickery), everything is automated in one click!
.prefer_dml 1
This modifies many of the built in commands (for example, lm) to display DML output which allows you to click links instead of running commands. Pretty handy...
.reload /f /o file.dll (the /o will overwrite the current copy of the symbol you have)
.enable_unicode 1 //Switches the debugger to default to Unicode for strings since all the Windows components use Unicode internally, this is pretty handy.
.ignore_missing_pages 1 //If you do a lot of kernel dump analysis, you will see a lot of errors regarding memory being paged out. This command will tell the debugger to stop throwing this warning.
alias alias alias...
Save yourself some time in the debugger. Here are some of mine:
aS !p !process;
aS !t !thread;
aS .f .frame;
aS .p .process /p /r
aS .t .thread /p /r
aS dv dv /V /i /t //make dv do your favorite options by default
aS f !process 0 0 //f for find, e.g. f explorer.exe
Another answer mentioned the command window and Alt + 1 to focus on the command input window. Does anyone find it difficult to scroll the command output window without using the mouse?
Well, I have recently used AutoHotkey to scroll the command output window using keyboard and without leaving the command input window.
; WM_VSCROLL = 0x115 (277)
ScrollUp(control="")
{
SendMessage, 277, 0, 0, %control%, A
}
ScrollDown(control="")
{
SendMessage, 277, 1, 0, %control%, A
}
ScrollPageUp(control="")
{
SendMessage, 277, 2, 0, %control%, A
}
ScrollPageDown(control="")
{
SendMessage, 277, 3, 0, %control%, A
}
ScrollToTop(control="")
{
SendMessage, 277, 6, 0, %control%, A
}
ScrollToBottom(control="")
{
SendMessage, 277, 7, 0, %control%, A
}
#IfWinActive, ahk_class WinDbgFrameClass
; For WinDbg, when the child window is attached to the main window
!UP::ScrollUp("RichEdit50W1")
^k::ScrollUp("RichEdit50W1")
!DOWN::ScrollDown("RichEdit50W1")
^j::ScrollDown("RichEdit50W1")
!PGDN::ScrollPageDown("RichEdit50W1")
!PGUP::ScrollPageUp("RichEdit50W1")
!HOME::ScrollToTop("RichEdit50W1")
!END::ScrollToBottom("RichEdit50W1")
#IfWinActive, ahk_class WinBaseClass
; Also for WinDbg, when the child window is a separate window
!UP::ScrollUp("RichEdit50W1")
!DOWN::ScrollDown("RichEdit50W1")
!PGDN::ScrollPageDown("RichEdit50W1")
!PGUP::ScrollPageUp("RichEdit50W1")
!HOME::ScrollToTop("RichEdit50W1")
!END::ScrollToBottom("RichEdit50W1")
After this script is run, you can use Alt + up/down to scroll one line of the command output window, Alt + PgDn/PgUp to scroll one screen.
Note: it seems different versions of WinDbg will have different class names for the window and controls, so you might want to use the window spy tool provided by AutoHotkey to find the actual class names first.
Script to load SOS based on the .NET framework version (v2.0 / v4.0):
!for_each_module .if(($sicmp( "##ModuleName" , "mscorwks") = 0) )
{.loadby sos mscorwks} .elsif ($sicmp( "##ModuleName" , "clr") = 0)
{.loadby sos clr}
I like to use advanced breakpoint commands, such as using breakpoints to create new one-shot breakpoints.
Do not use WinDbg's .heap -stat command. It will sometimes give you incorrect output. Instead, use DebugDiags memory reporting.
Having the correct numbers, you can then use WinDbg's .heap -flt ... command.
For command & straightforward (static or automatable) routines where the debugger is used, it is very cool to be able to put all the debugger commands to run through in a text command file and run that as input through kd.exe or cdb.exe, callable via a batch script, etc.
Run that whenever you need to do this same old routine, without having to fire up WinDbg and do things manually. Too bad this doesn't work when you aren't sure what you are looking for, or some command parameters need manual analysis to find/get.
Platform-independent dump string for managed code which will work for x86/x64:
j $ptrsize = 8 'aS !ds .printf "%mu \n", c+';'aS !ds .printf "%mu \n", 10+'
Here is a sample usage:
0:000> !ds 00000000023620b8
MaxConcurrentInstances