Bug 2544 - Crash reporter problems
Summary: Crash reporter problems
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: Trunk
Hardware: PC Mac OS
: Highest major
Target Milestone: ---
Assignee: Alan McGovern
Depends on:
Reported: 2011-12-16 15:01 UTC by Mikayla Hutchinson [MSFT]
Modified: 2011-12-21 10:01 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Mikayla Hutchinson [MSFT] 2011-12-16 15:01:49 UTC
The first time MD has an unhandled exception, the crash reporter shows a dialog saying that a "crash" has occurred and asking the user to enable submission.

This has several problems
a) It's not a crash, the text is incorrect
b) The actual exception is not shown, so users cannot file it manually, and do not see the kind of information that will be submitted
c) There is no option to submit just this one error

On subsequent unhandled exceptions, MD shows the trace, with the message "An unhandled exception has occurred. Details of this crash have been submitted for analysis. This has several issues:
a) The vertical scrollbar is not visible, but the body of the detail text is taller than the text widget - it can be scrolled by drag-selecting.
b) The text is incorrect, it's not a crash
c) The text is too technical, it shouldn't refer to unhandled exceptions, it should say something like:
"MonoDevelop has encountered an unexpected error and may not have completed the operation successfully. Details of this error have submitted for analysis."
d) The exception detail should not be shown by default, it should be shown in a collapsed expandable box.

In addition, the unhandled exceptions no longer appear to be written to the MonoDevelop log files.

Also, the new rotated log files are confusing because there's a lot of information out there that says to check MonoDevelop.log, which will now always be stale. IMO MD should either link MonoDevelop.log to the latest log file, or delete it.
Comment 2 Alan McGovern 2011-12-19 06:05:29 UTC
The first time:
a) Good point. It is not always a crash and this text can be cleaned up to properly explain this.

b) This is by design. The opt-in/out dialog was not supposed to display any sort of crash info.

c) Again, by design. If the user opts out then every future crash dialog will say something along the lines of "This has not been submitted as crash reporting has been disabled". This is their on-going reminder to opt in.

On subsequent exceptions:
a) The property set to enable vertical scrolling was accidentally removed. It's already back in

b) There needs to be two sets of text, one for an actual crash which terminates MD and one for when it doesn't. I'll add latter.

c) Good point

d) I wanted to ping you about this as I had trouble finding the correct MonoMac control to implement this behaviour.

Log files:
This is something I noticed too but haven't changed as of yet. I was thinking of writing the log files to MonoDevelop.log and then when MD starts up, renaming the existing MonoDevelop.log to the form:
MonoDevelop-{DateTime.Now.ToString ("yyyy-mm-dd_hh:mm:ss")}.log

This way the latest is always called "MonoDevelop.log" (an expectation we should keep if at all possible) and the user will trivially be able to relate an older log file to an exact session. The session uuid will be written inside the log instead of being part of the filename.
Comment 4 Mikayla Hutchinson [MSFT] 2011-12-19 11:02:44 UTC
b) Then how are users supposed to know what information we are submitting, and if they opt out how can they manually report that first error?

c) That's a shame, I'm sure we'd get more reports if we had an option to report individual errors.

d2) Yeah, this kind of thing is complicated, IIRC there's a specific kind of button you have to use then manually resize the window and add the new control in but you you can get the slidey-widow thing going.

Log files:
The problem with renaming on next session is that multiple instances of MD will still collide. What the matter with a link?
Comment 5 Mikayla Hutchinson [MSFT] 2011-12-19 11:05:24 UTC
Also, cmd-c etc don't work in the details textview.
Comment 6 Alan McGovern 2011-12-20 08:38:34 UTC
Command-c/a/x now work. I never tested that behaviour and didn't realise it didn't work by default. I've implemented the UI for always/just this time/never as part of a combined "opt-in and display information" dialog.
Comment 7 Alan McGovern 2011-12-21 10:01:39 UTC
I sorted out the MonoDevelop.log file issue. This is a symlink to the latest file on linux/macos. On windows we rename MonoDevelop.log to MonoDevelop.[TIME_STAMP].log on startup and also handle the case where there are multiple concurrent monodevelop instances.

I think all the issues have been resolved so marking this as resolved for now, but do reopen if I missed something!