My latest laundry list of feature requests:

WINDBG
1

I love the new windbg… I’ve even starting using it over
dev studio for anything of even moderate complexity.

And a big thanks to the debugger team for the new
functionality that finds my derived objects from the base class
pointers. That is a life saver!

Since you implemented my last feature request, I have
a laundry list of more features :slight_smile:

  1. Put the official email address to send these things
    (feature requests) where I’m looking for it :slight_smile:

Seriously, I’m pretty sure it is in the documentation
somewhere, but no section looks like an obvious
canidate, searching for “feedback” didn’t get anything
useful, and “comments” got all pages.

Someplace right around legal Information (i.e., the
very top of the documentation) is where I always look
for it.

  1. Is there a way I can have a “disassembly w/ source” mode
    where I can see my source code mixed in with the
    dissassembly (visual studio has an option to produce
    .asm listing files like this.

I’m becomming more proficient with assembly all the time,
but it is easy to get lost in a maze of twistly little
opcodes that all look identical.

  1. Is there a way we can have a scroll bar in the disassembly window?
    Maybe just set the range large, and don’t move the thumb or
    something.

Actually, how about if the range was from the begginning to the
end of the function (if I’m in one.)

  1. The scroll bar in the memory window doesn’t really work that well…
    that one would probably just need to be set with a large range and
    keep the thumb in the middle. So to scroll alot one might have to
    drag the thumb to the bottom (which maybe would scroll through
    1 MB of memory or maybe 16 or some arbitirary number) and then
    drop it. It would automatically reset to the middle and one
    could repeat.

  2. If I have a selection in the memory window and use the mouse wheel,
    I loose my selection. I use the selection to keep track of where I
    am amidst all those numbers.

  3. Is there a way to examine the exception chain? I.e., fs:[00000000]
    back through the stack. I sometimes use this to help with a broken
    stack walk (or to orient myself in the memory window when I’m trying
    to decode a stack to find a local variable or where some routine
    stashed the this pointer.)

  4. How about a combo box MRU for the Offset: field in the dissasembly
    window… I find myself popping around various functions that have
    been recently called etc. when I’m debugging.

  5. The hardest thing about debugging my application crashes is that
    without fail ‘this’ is wrong. I have to disassemble functions
    on the stack and crawl around looking for where someone stashed
    ecx on the stack to recover it.

  6. Local variables are never right (it seems anyway.) In the crash
    dump I’m debugging now, they have not been optimized away or
    gone out of scope (I can find them manually with enough work.)

Thanks,

Joseph

2

Thanks very much for the feedback. I’ll take this back to the team, and
come back with some more answers. But here’s a short version:

  1. Didn’t you check the last paragraph of the release notes? It points
    you to xxxxx@microsoft.com. That’s the first place I would check :slight_smile:

  2. optimization makes this hard when code gets rearranged. But there is
    an option to show line numbers mixed into the disassembly. And another
    which highlights the asm lines which are part of the current
    instruction.

  3. We’ve debated this a couple times. When it comes down to it, the
    range is huge, and limiting it to just the function could get in the
    way. So the scroll bar would be pretty much useless. If I remember
    correctly, we did hook the mouse wheel up to try and ease the pain.

  4. I haven’t played with it recently. I’ll check it out.

  5. Will check it out

  6. !exchain?

  7. Will check it out.

  8. Optimized code. Unfortunately, the information in the pdb file is
    frequently incorrect for optimized code. There is a long-term work item
    on the compiler team to fix this up, but that is not likely coming
    anytime soon.

  9. Same as #8.

And finally, I might as well say that I wish you’d have sent this
feedback 3 weeks ago, when we could have implemented some changes. We
just finalized the bits for the next debugger release, coming *soon*

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Monday, June 27, 2005 8:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] My latest laundry list of feature requests:

I love the new windbg… I’ve even starting using it over
dev studio for anything of even moderate complexity.

And a big thanks to the debugger team for the new
functionality that finds my derived objects from the base class
pointers. That is a life saver!

Since you implemented my last feature request, I have
a laundry list of more features :slight_smile:

  1. Put the official email address to send these things
    (feature requests) where I’m looking for it :slight_smile:

Seriously, I’m pretty sure it is in the documentation
somewhere, but no section looks like an obvious
canidate, searching for “feedback” didn’t get anything
useful, and “comments” got all pages.

Someplace right around legal Information (i.e., the
very top of the documentation) is where I always look
for it.

  1. Is there a way I can have a “disassembly w/ source” mode
    where I can see my source code mixed in with the
    dissassembly (visual studio has an option to produce
    .asm listing files like this.

I’m becomming more proficient with assembly all the time,
but it is easy to get lost in a maze of twistly little
opcodes that all look identical.

  1. Is there a way we can have a scroll bar in the disassembly window?
    Maybe just set the range large, and don’t move the thumb or
    something.

Actually, how about if the range was from the begginning to the
end of the function (if I’m in one.)

  1. The scroll bar in the memory window doesn’t really work that well…
    that one would probably just need to be set with a large range and
    keep the thumb in the middle. So to scroll alot one might have to
    drag the thumb to the bottom (which maybe would scroll through
    1 MB of memory or maybe 16 or some arbitirary number) and then
    drop it. It would automatically reset to the middle and one
    could repeat.

  2. If I have a selection in the memory window and use the mouse wheel,
    I loose my selection. I use the selection to keep track of where I
    am amidst all those numbers.

  3. Is there a way to examine the exception chain? I.e., fs:[00000000]
    back through the stack. I sometimes use this to help with a broken
    stack walk (or to orient myself in the memory window when I’m trying
    to decode a stack to find a local variable or where some routine
    stashed the this pointer.)

  4. How about a combo box MRU for the Offset: field in the dissasembly
    window… I find myself popping around various functions that have
    been recently called etc. when I’m debugging.

  5. The hardest thing about debugging my application crashes is that
    without fail ‘this’ is wrong. I have to disassemble functions
    on the stack and crawl around looking for where someone stashed
    ecx on the stack to recover it.

  6. Local variables are never right (it seems anyway.) In the crash
    dump I’m debugging now, they have not been optimized away or
    gone out of scope (I can find them manually with enough work.)

Thanks,

Joseph

You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Jason Shay wrote:

Thanks very much for the feedback. I’ll take this back to the team, and
come back with some more answers. But here’s a short version:

  1. Didn’t you check the last paragraph of the release notes? It points
    you to xxxxx@microsoft.com. That’s the first place I would check :slight_smile:

Ah, that’s where it is.

Unfortunately, I tend to read the release notes when I install and never
look at them again.

I still think someplace near the top of the documentation would be a
good place to include it in addition to the release notes.

  1. optimization makes this hard when code gets rearranged. But there is
    an option to show line numbers mixed into the disassembly.

Excellent. It would be perfect if this could be expanded to actually
display the line from the source file inline. (I know it would end up
slightly out of order and wonky, but just something close will help
me keep track of what I’m looking at.

  1. We’ve debated this a couple times. When it comes down to it, the
    range is huge, and limiting it to just the function could get in the
    way. So the scroll bar would be pretty much useless. If I remember
    correctly, we did hook the mouse wheel up to try and ease the pain.

Yes, I do use the wheel.

Maybe there could be some sort of heursitic where if you scroll to the
end of the function and then try to scroll farther it pops you into the
next function. Or maybe it could be an optional mode. Or
maybe it could work as I described the memory window working… set
the range large (so the thumb is small and has a lot of play) and
always reset the thumb to the middle after a scrolling option.

  1. I haven’t played with it recently. I’ll check it out.

  2. Will check it out

  3. !exchain?

Thanks!

  1. Will check it out.

  2. Optimized code. Unfortunately, the information in the pdb file is
    frequently incorrect for optimized code. There is a long-term work item
    on the compiler team to fix this up, but that is not likely coming
    anytime soon.

How incorrect?

The function I was debugging, the offsets seemed correct relative to
each other, but not relative to the frame base. In other words, to
use the offsets displayed by dv /V by applying the same small offset
to all of them (in my case, I believe it was -4) Is this the typical
case, or did I just get lucky?

If that is the typical case, what would be incredibly useful in the
short term (and for those of us stuck with code built on a compiler
before they fix it) would be a pseudo-register that I can update
to shift the frame base used for locals. Then I can manually figure
it out, enter the value that is corrected, and bingo! all my locals
will work.

  1. Same as #8.

I suspected that for this one…

Here is a wild feature request … probably one of those I would look
at as a developer and groan :slight_smile:

When I look at what I have to do to find the this pointer,
I realized that what would really help is:

10.) “Stack view” in the memory window. This view would probably
look something like this:

0012e5fc 0012ec4c
1604aa8b
0012ecac
00000001
0012e60c 015a03b0
0012ed5c
0012ec4c
0000000a Frame base for MyClass::FunctionX
0012e61c 1604a8bb MyClass::OnInitDialog + 0x21b
00000000
00000000
5f405ddc
0012e62c 0012e680
000207e4
015cde60
015cdff0
0012e63c 01567bcc
01596424
00000000
0012e6dc
0012e64c 16071000
00000005 Frame Base for MyClass::OnInitDialog
5f405e13 Mfc42!AfxDlgProc+0x2e
…

(Not displaying the offset at every line makes it not quite
so dense to read.)

11.) An option to analyze a (very small) section of assembly at the
beginning of a function and annotate the “stack view”

What I’m imagining is that it would analyze the function code
until the first conditional branch and annotate the stack
view with which slots contain the arguments, saved registers, etc.

This would be incredibly useful. (It should also be cumulative…
the “stack view” should update as I move around in the call
window and ask for additional analysis.)

So, if my current frame where MyClass::OnInitDialog, and
first instructions looke like this:

push 0xff
push 0x16071000
mov eax,fs:[00000000]
push eax
mov fs:[00000000],esp
sub esp,0x14
push ebx
push ebp
push esi
push edi
mov edi,ecx
call MyBaseClass::OnInitDialog (16061430)
mov ecx,[edi+0xf8]
mov [esp+0x20],eax
lea eax,[esp+0x18]
add ecx,0x38
push eax
or ebp,0xffffffff
or ebx,0xffffffff

Then the “stack view” above would be updated with:

0012e5fc 0012ec4c
1604aa8b
0012ecac
00000001
0012e60c 015a03b0
0012ed5c
0012ec4c
0000000a Frame base for MyClass::FunctionX
0012e61c 1604a8bb MyClass::OnInitDialog + 0x21b
00000000 eax
00000000 edi [new edi value: ecx (this)]
5f405ddc esi
0012e62c 0012e680 ebp
000207e4 ebx
015cde60
015cdff0
0012e63c 01567bcc
01596424
00000000
0012e6dc Previous exception frame
0012e64c 16071000 Frame exception handler
00000005 Frame Base for MyClass::OnInitDialog
5f405e13 Mfc42!AfxDlgProc+0x2e

A couple of frames of that and I find my this pointer on the
stack.

And finally, I might as well say that I wish you’d have sent this
feedback 3 weeks ago, when we could have implemented some changes. We
just finalized the bits for the next debugger release, coming *soon*

Ah, shucks :slight_smile:

Me too. That would have meant I was debugging this crash
in beta code instead of official release :slight_smile:

Thanks,

Joseph