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+