Excel 2011 not enough memory error and AutoRecovery files

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

~/Library/Application
Support/Microsoft/Office/Office 2011 AutoRecovery

. For Microsoft Office 2008 for Mac they are stored at

~Documents/Microsoft User Data/Office
2008/AutoRecovery

$
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

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 was named ~$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 command.

$ 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 the 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 ~/Library/Logs/DiagnosticReports/, 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-[36650] stack overflow
--
/Users/jasmith1/Library/Logs/DiagnosticReports/Microsoft Excel_2016-03-14-211653_GSSLA15122293.crash-[36696] stack overflow
--
/Users/jasmith1/Library/Logs/DiagnosticReports/Microsoft Excel_2016-04-11-143908_GSSLA15122293.crash-[469] 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 named pending_removal.csv open in Excel.

$ ls ~/Library/Application\ Support/Microsoft/Office/Office\ 2011\ AutoRecovery
AutoSave to 5FD538B5pending_removal.csv