If I chose to reopen all of the workbooks, it would display the message "Not enough memory." then crash again. The problem occurred even after I closed other applications that were open and rebooted the system to minimize the amount of memory used by other processes running on the system.
Whenever you attempt to reopen Excel after it has crased with files open,
it may prompt you to recover changes to those files from AutoRecovery files
it created. The AutoRecovery files for Microsoft Office 2011 are
stored under a user's home directory at
Support/Microsoft/Office/Office 2011 AutoRecovery. For Microsoft Office 2008 for Mac they are stored
~Documents/Microsoft User Data/Office
$ ls ~/Library/Application\ Support/Microsoft/Office/Office\ 2011\ AutoRecovery AutoRecovery save of Normal.dotm CNE_Requests (version 1).xlsb CRQ000000342949_DCS (version 1).xlsb DCS for CRQ-328242 NSR-38406 (version 1).xlsb ~$CNE_Requests (version 1).xlsb ~$CRQ000000342949_DCS (version 1).xlsb ~$DCS for CRQ-328242 NSR-38406 (version 1).xlsb ~$MSGRS (version 1).xlsb
The files are stored as
Excel binary worksheet (BIFF12) .xlsb files, even if the original file
you had opened was an
Excel Binary File Format .xls or
Office Open XML-based and macro-enabled file - see
File formats that are supported in Excel for further information on Excel
file formats. The XLSB format is also
referred to as BIFF12, which stands for "binary file format for Office 12",
which was introduced in
Microsoft Office 2007, which was codenamed "Office 12", and supported in
Microsoft Office 2008 for Mac and later versions. An XLSB
file is a ZIP container
as are .docx files
created by Microsoft Word. On a Mac OS X system, you can extract the
contents of a .xlsb file, if it hasn't been corrupted by an Excel crash, from a
command line interface (CLI) using the
application found in
I copied one of the files that I had edited, for which I needed the latest
version to retain changes I had made to the document in the last week, to
another location, but found that it was only 171 bytes, far too
small to contain all of the data in the spreadsheet. The original
file name was
MSGRS.xls whereas the AutoRecovery file
~$MSGRS (version 1).xlsb . Note: if you see
a "$" in the file name you will need to "escape" its meaning with
a backslash character which serves as an
escape character, taking away its special meaning to a
Bash shell, when copying the file with the
$ cp "/users/jdoe/Library/Application Support/Microsoft/Office/Office 2011 AutoRecovery/~\$MSGRS (version 1).xlsb" test.xlsb $ ls -lhg test.xlsb total 8 -rw-r--r--@ 1 NDC\Domain Users 171B Mar 23 17:42 test.xlsb
Note: if you are copying the file from directory where Microsoft Office stores the AutoRecovery files from a Terminal window without enclosing the path in quotes, you will also need to use the backslash character to "escape" the spaces and parentheses by placing it immediately before those characters. Otherwise you will receive an "unexpected token error message.
$ cp ~/Library/Application\ Support/Microsoft/Office/Office\ 2011\ AutoRecovery/~\$MSGRS\ (version\ 1).xlsb MSGRS.xlsb -sh: syntax error near unexpected token `(' $ cp ~/Library/Application\ Support/Microsoft/Office/Office\ 2011\ AutoRecovery/~\$MSGRS\ \(version\ 1\).xlsb MSGRS.xlsb $
In this case, I couldn't extract the contents for the .xlsb file with
unzip utility, since it was a corrupted, incomplete file.
$ unzip test.xlsb Archive: test.xlsb End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of test.xlsb or test.xlsb.zip, and cannot find test.xlsb.ZIP, period.
On a system running Apple's OS X operating system, crash reports for a
user's account are stored in
so I checked on the file name for the last Excel crash report. Crash reports
are stored with a file name that begins with the application name, which
is followed by a time stamp, then the name of the system, and then a
.crash at the end of the file name.
$ ls ~/Library/Logs/DiagnosticReports/ | grep Excel Microsoft Excel_2016-03-11-114210_GSSLA15122293.crash Microsoft Excel_2016-03-11-141557_GSSLA15122293.crash Microsoft Excel_2016-03-14-211154_GSSLA15122293.crash Microsoft Excel_2016-03-14-211653_GSSLA15122293.crash Microsoft Excel_2016-04-11-143908_GSSLA15122293.crash $
When I checked on what was listed for the cause of the crash in the files
by looking for the line that immediately follows the "Application Specific
Information:" line in the files with
grep -A 1 "Application Specific
Information:, I saw "stack overflow" listed for the last three crashes.
$ grep -A 1 "Application Specific Information:" ~/Library/Logs/DiagnosticReports/Microsoft\ Excel_*.crash | grep -v "Application" /Users/jasmith1/Library/Logs/DiagnosticReports/Microsoft Excel_2016-03-14-211154_GSSLA15122293.crash- stack overflow -- /Users/jasmith1/Library/Logs/DiagnosticReports/Microsoft Excel_2016-03-14-211653_GSSLA15122293.crash- stack overflow -- /Users/jasmith1/Library/Logs/DiagnosticReports/Microsoft Excel_2016-04-11-143908_GSSLA15122293.crash- stack overflow $
I wasn't able to determine the cause of the stack overflow, but, since
I saw several files only 171 bytes in length in the AutoRecovery directory,
which meant I wouldn't actually be able to use them to recover any recent
changes, and, other than the
MSGRS.xls one, which
appeared to be unrecoverable at this point, I didn't need to recover
any of the others, I chose to reopen Excel again, but not attempt
to reopen any of the previously opened files when I was prompted
to reopen them. That allowed Excel to open normally without crashing.
After re-entering data into the last saved version of the
MSGRS.xls spreadsheet, when I closed Excel, I saw that
there were no longer any files in the AutoRecovery folder.
$ ls ~/Library/Application\ Support/Microsoft/Office/Office\ 2011\ AutoRecovery $
I later noticed that Excel, when it
autosaves documents, will
put a file with "AutoSave" at the beginning of the file name in the
AutoRecovery directory. E.g., I saw the following when I had a file
pending_removal.csv open in Excel.
$ ls ~/Library/Application\ Support/Microsoft/Office/Office\ 2011\ AutoRecovery AutoSave to 5FD538B5pending_removal.csv