When a macOS native Helix application crashes, a file containing detailed information about the crash is automatically created. However, Apple’s built-in Crash Reporter (the window that comes up after a crash, asking you to describe the events preceding the crash) only sends the report to Apple — and Apple does not forward them to us.
If we are to continue to improve the product and meet the needs of our customers, we need to know when you experience problems. If you are experiencing crashes, we encourage you to report them us, so we can fix them. The rest of this page explains how you can retrieve the system-generated crash logs and submit them to us in a way that allows us to efficiently deal with them.
Please note that we do not, in general, ask you to submit crash logs via email. Why not? Because it is inefficient. If you email them to us, the person receiving the email must then turn around and load the crash log into the support database. At this point, the entry goes in without your customer number (unless you happened to provide it) and we have lost the ability to contact you, the person actually affected by the crash, directly. By submitting the crash log yourself, you give us an efficient way to contact you if we need further information or we have a fix for the bug.
That said, there are times when it makes sense for you to email your crash logs to technical support so we can ‘preview’ them before creating an official report. If you are uncertain, feel free to contact technical support first.
When a macOS native Helix application crashes, a file is created containing details about the crash that may help us isolate and fix it. How to locate this crash log varies depending on which version of macOS you are running:
- Lion and Later: Under macOS 10.7 and later, crash logs are stored in the same location as Snow Leopard, but the ‘Library’ folder is hidden from view. The easiest way to get there is to hold down the Option key before clicking the Go menu in the Finder’s menu bar — the ‘Library’ folder will be shown in the list: choose it to open it, then navigate into the /Logs/DiagnosticReports/ folder.
- Snow Leopard: Under macOS 10.6, each crash is written to a separate time stamped crash log file, just as they are in macOS 10.5 (Leopard). However, the crash log files are stored in the User’s ~/Library/Logs/DiagnosticReports/ folder. (In Snow Leopard, the “CrashReporter” folder contains aliases to the actual files: be careful not to send us the aliases!)
- Leopard: Under macOS 10.5, crash logs are stored in the same location, but multiple crashes are no longer written to a single file. Each Leopard crash is written to a uniquely time stamped crash log file. On a Mac running macOS 10.5, a crash log is named e.g. “Helix Server_2008_10_22_123456_username.crash” to show the date, time and username of the crash. Be sure to get the right log file(s) when sending them to us. (You can — and should — delete the old crash logs, as they are now irrelevant.)
- Tiger: Under macOS 10.4, all of the crashes for a program are written into a single file. That file is in the User’s ~/Library/Logs/CrashReporter/ directory. The file is named after the program, with .crash.log appended to the end. If you have never accessed this file before, it is probably filled with old, irrelevant information. If the file is more than a few kilobytes in size, please don’t send it. Discard it and try to reproduce the crash. The new crash log will contain just the information we need to see your current issue.
Feel free to read the crash log, but be very careful not to change anything in it. Double clicking a crash log typically opens the Console application, but you can drag them onto any text editor. The important thing is that you have found the information we need to understand why your Helix application is crashing.
With crash log in hand, you are ready to log into our technical support database (techdb) and send it to us. If you are not familiar with techdb, this page tells you how to access it.
Once you have logged in, the Bug Reports menu contains views you can use to search existing reports. You should take a moment to see if somebody else has already reported the same crash situation. Try searching for ‘Client Crash’ or ‘Print Crash’ or whatever you think will find a report similar to what you are seeing.
If you find an existing report, attach your crash logs via the Support Documents feature of the bug reporter, and provide in the Discussion any details you think will help us determine the cause of the crash. If there is no crash report similar to yours, create a new bug report describing the situation surrounding your crash.
Crash logs (and other support files such as sample collections) are attached via the “Support Documents” section of the Bug Report, as shown on the right. Note that this section is disabled until you create the report. Creating a report assigns it a report number, which is necessary for associating the attachment with the report.
When you click the Add Document button, a new form opens (see at left). Enter your customer number and password, then add any useful notes. When you tab (or click) into the Document field the Get Document button activates.
Clicking it opens the macOS file browser (see at right) which you use to specify a document to send. Navigate to the crash log and click the Copy File button. You can also drag your document directly from the Finder and drop it into the document field or macOS file browser window. Either way, when you enter the record (click the Add Document button), Helix transfers the file into techdb and returns you to the main bug report window. You can now add additional information, or just close the view and go on to other things.
Final note: by default, any documents you upload are available for other Helix users to see. This is to encourage the free-flow of information. If you prefer that your document not be accessible to other Helix users, click the Private radio button before adding the document. Only QSA ToolWorks (and you) are able to access a private document.
Our staff reviews the submitted documents and searches for patterns that can be used to isolate and fix the bugs. We may have follow up questions, so be sure to come back to techdb in a day or two and see if we are requesting further input from you. (The ‘Find My Reports’ view was made for this very purpose.)
If your bug is affecting a mission critical application, feel free to follow up with an email to our support department, letting us know about the document you uploaded. We’ll take a quick look and let you know if we have any insight into your particular issue.
But please understand: fixing bugs is typically a task that is measured in weeks, not days or hours. The chances of us being able to find the bug, fix the bug, test the fix, build a new version of Helix, and distribute that fix in time for your next business day are non-existent. This is the harsh reality of most of the bugs we have seen.
CrashReporter is a debugging facility in macOS that logs information about all programs that crash. For more information about crash logs and CrashReporter, check out this technote from Apple.
For the more technically minded, here is a useful article on crash logs.