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+
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
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+
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
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/...
-
Eric Pouech -
Mike Hearn -
Mike Hearn