Paul Chitescu paulc@voip.null.ro writes:
Changelog: kernel32: Send exception information to winedbg for display in the crash dialog
That info (and more) can be determined by the debugger itself, there's no need to pass it from kernel32.
On Wednesday 29 April 2009 18:02:17 Alexandre Julliard wrote:
Paul Chitescu paulc@voip.null.ro writes:
Changelog: kernel32: Send exception information to winedbg for display in the crash dialog
That info (and more) can be determined by the debugger itself, there's no need to pass it from kernel32.
True, but that would mean replicating the code in except.c format_exception_msg(). Getting the two pieces of code out of sync would cause user confusion as some will report the string displayed in the crash window while others will report the message from start_debugger().
I have also concerns about the message box that is displayed inside start_debugger() if the debugger is not to be started automatically - is it safe to assume the process is still capable to run the message loop for the window?
Paul Chitescu
Paul Chitescu paulc@voip.null.ro writes:
True, but that would mean replicating the code in except.c format_exception_msg(). Getting the two pieces of code out of sync would cause user confusion as some will report the string displayed in the crash window while others will report the message from start_debugger().
I don't think that's a problem at all. Plus to do this right you need the real info, not just a string. For instance we most likely want a completely different message box for stub exceptions, we don't want a dialog at all for ^C, etc.
And if we handle these meaningful exceptions properly, I doubt we want to show anything more in the default dialog. Users don't need to know if the exception was a page fault or an illegal instruction. We can of course have a "show details" button that shows the whole backtrace info.
I have also concerns about the message box that is displayed inside start_debugger() if the debugger is not to be started automatically - is it safe to assume the process is still capable to run the message loop for the window?
No, of course it doesn't always work, but even simply starting the debugger cannot always work either, there's nothing we can do about that.