June 12, 2004
5:13 p.m.
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+