Re: Implement a --backtrace-all mode for winedbg

[Eric Pouech]

I'm not sure I understand the purpose of the --backtrace-all.
There's no way you can ensure a complete synchro between all threads & 
processes to get a global picture of the whole system, so the option is 
likely not very useful (except for the threads which are in a wait 
operation), but you will miss some other information for that (ie an 
event (entering/leaving CS...) tracker tool would be better).
More over, I don't like either adding options to winedbg. So, I'd prefer 
adding an option to actually process the commands from a file (or even a 
string from command line) would be better.
And, finally, you leak the handle for the snapshot.
A+

Implement a --backtrace-all mode for winedbg

[Mike Hearn]

On Fri, 2004-06-11 at 20:55 +0200, Eric Pouech wrote:
> I'm not sure I understand the purpose of the --backtrace-all.

When a user says "I pressed this button and the app hung" it's
convenient to have *somewhere* to start from - this is another attack
vector.
> There's no way you can ensure a complete synchro between all threads & 
> processes to get a global picture of the whole system

Yes, I know that, but it doesn't have to be precise. For the situations
I'm thinking of most of the (interesting) threads will be blocked
waiting for an event or deadlocked on a critical section anyway. It's
common enough to have some automatic *easy* command we can give to a
non-technical user.

At the moment you have to teach them how to start winedbg, walk the
process list, attach to it, walk the threads list, get a backtrace for
each thread etc if you decide you want to see some backtraces. This is
(a) complicated and (b) some non-technical users can't do it, it's too
many steps.

This way we can reduce it to: Please run "winedbg --backtrace-all >log"
when the app hangs, and send us the "log" file.
> , so the option is 
> likely not very useful (except for the threads which are in a wait 
> operation), but you will miss some other information for that (ie an 
> event (entering/leaving CS...) tracker tool would be better).

It's just somewhere to start from, rather than a cutting edge debugging
tool :)
> More over, I don't like either adding options to winedbg. So, I'd prefer 
> adding an option to actually process the commands from a file (or even a 
> string from command line) would be better.

Well, as I said the reason I'd like this is because it's super easy.
Processing commands from the command line would be nice but that's not
something you can put in an email or on IRC to a confused user. They'll
just get it wrong, and you still need to know PIDs and TIDs and such.
This is easier for them.
> And, finally, you leak the handle for the snapshot.

Oops! I'll send a fixed version.

thanks -mike

Implement a --backtrace-all mode for winedbg

[Eric Pouech]

Mike Hearn a écrit :
> On Fri, 2004-06-11 at 20:55 +0200, Eric Pouech wrote:
> > I'm not sure I understand the purpose of the --backtrace-all.
>
> When a user says "I pressed this button and the app hung" it's
> convenient to have *somewhere* to start from - this is another attack
> vector.

well, in that case the mini-dumps are the way to go (even if they don't 
have the pre-defined semantics for system wide thread information, but 
they do have what you need). This will embed more details that what 
you've done (OS version, loaded modules...)
> > There's no way you can ensure a complete synchro between all threads & 
> > processes to get a global picture of the whole system
>
> Yes, I know that, but it doesn't have to be precise. For the situations
> I'm thinking of most of the (interesting) threads will be blocked
> waiting for an event or deadlocked on a critical section anyway. It's
> common enough to have some automatic *easy* command we can give to a
> non-technical user.
>
> At the moment you have to teach them how to start winedbg, walk the
> process list, attach to it, walk the threads list, get a backtrace for
> each thread etc if you decide you want to see some backtraces. This is
> (a) complicated and (b) some non-technical users can't do it, it's too
> many steps.
>
> This way we can reduce it to: Please run "winedbg --backtrace-all >log"
> when the app hangs, and send us the "log" file.

agreed on a user friendliness of the operation. My idea with mini-dump 
is that we could use this vector to get back information from any user 
after any problematic operation:
- a crash
- an app hanging up...
> > More over, I don't like either adding options to winedbg. So, I'd

prefer
> > adding an option to actually process the commands from a file (or even a 
> > string from command line) would be better.
>
> Well, as I said the reason I'd like this is because it's super easy.
> Processing commands from the command line would be nice but that's not
> something you can put in an email or on IRC to a confused user. They'll
> just get it wrong, and you still need to know PIDs and TIDs and such.
> This is easier for them.

I was thinking of (for your example, even if I still don't like the 
idea) of:
- adding a new command to winedbg (say 'bt *' to get what you described)
- add a new option to winedbg, which is run the command passed in 
parameter. so, the command line would be winedbg -e 'bt *' (we could 
this way have better flexibility if needed).
I was not talking about asking the user to do 'info proc' at the winedbg 
prompt followed by a bt <tid> for each known thread id

A+

Implement a --backtrace-all mode for winedbg

[Mike Hearn]

On Sat, 12 Jun 2004 19:13:05 +0200, Eric Pouech wrote:
> well, in that case the mini-dumps are the way to go (even if they don't 
> have the pre-defined semantics for system wide thread information, but 
> they do have what you need). This will embed more details that what 
> you've done (OS version, loaded modules...)

What is a minidump? I saw them mentioned in the todo list but there weren't 
many details.
> I was thinking of (for your example, even if I still don't like the 
> idea) of:
> - adding a new command to winedbg (say 'bt *' to get what you described)
> - add a new option to winedbg, which is run the command passed in
>
> parameter. so, the command line would be winedbg -e 'bt *' (we could 
> this way have better flexibility if needed).
> I was not talking about asking the user to do 'info proc' at the winedbg 
> prompt followed by a bt <tid> for each known thread id

Yes, that would work too, though I'd expect bt * to backtrace every thread in 
the current process, whereas --backtrace-all does all the threads in every
process (which is useful if there are two processes and one is blocked on the other).

thanks -mike

Implement a --backtrace-all mode for winedbg

[Eric Pouech]

> What is a minidump? I saw them mentioned in the todo list but there weren't 
> many details.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/...