Excel 2011 not enough memory error and AutoRecovery files

Microsoft Excel for Mac 2011 was crashing whenever I attempted to open it on a MacBook Pro laptop I use. Whenever I attempted to reopen it, I would be presented one by one with files to reopen that had been open when it crashed.

Excel 2011 saved changes

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.

Excel 2011 - not enough memory

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

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 Terminal application found in /Applications/Utilities, e.g. unzip example.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


  1. Microsoft Excel quit unexpectedly
    Date: March 11, 2016
    MoonPoint Support
  2. New Binary File Format for Spreadsheets
    By: Doug Mahugh/Microsoft
    Date: August 22, 2006
    Microsoft Software Developer Network (MSDN) Blogs
  3. Determining the version of Microsoft Word used to edit a .docx Document
    Date: December 31, 2104
    MoonPoint Support
  4. File formats that are supported in Excel
    Microsoft Office help and training - Office Support


TechRabbit ad 300x250 newegg.com

Justdeals Daily Electronics Deals1x1 px