Excel 2003, Windows XP SP3:
We have a number of Excel users who work with very large, complex Excel workbooks. A typical workbook may have 60+ worksheets and be upwards of 70MB in size. We have an .xll addin that we produce and is used throughout these spreadsheets. We have extensive debugging and logging capabilities with our addin. We have been producing versions of the addin and using them for almost 10 years. The infrastructure for our Excel interface is thus provenly rubust and stable.
There are certain situations in which Excel hangs in a particular piece of code; that is, it hangs within code in Excel itself, and it hangs at one particular piece of code. In this case, there is a tight loop of code (maybe 20 machine instructions, with no “call”s) that it executes endlessly. The code appears to be walking a linked list that is circular, often with few nodes, e.g. only four nodes. I looks to me like it is walking a linked list that corresponds to (some part of) the evaluation tree – I am not sure at all though.
I have been able to manifest the behaviour with an incredibly simple addin (3 registered functions that return fixed data) and an incredibly simple spreadsheet (5 cells, 3 formulas using the 3 addin functions). Excel hangs only after completing evaluation of all the cells in the worksheet and after having updated the screen with the results. It hangs regardless of which Excel SDK version is used (v5.0, v12.0 and v14.0 all tested).
Here is a link to sample code: Sample .xls workbook and corresponding .xll addin and source for addin
The source for the addin is trivial:
#include <windows.h>
#if SDK_VER == 5
#include "xlcall_v5_0.h"
#elif SDK_VER == 12
#include "xlcall_v12_0.h"
#elif SDK_VER == 14
#include "xlcall_v14_0.h"
#endif
extern "C" __declspec(dllexport) int xlAutoOpen(void) {
#define N_FUNCTIONS 3
#define N_FUNCTION_REGISTRATION_PARAMETERS 3
char* rgFuncs[N_FUNCTIONS][N_FUNCTION_REGISTRATION_PARAMETERS] = {
{"\013FunctionOne", "\002RP", "\013FunctionOne"},
{"\013FunctionTwo", "\002RP", "\013FunctionTwo"},
{"\014FunctionFour", "\003RBP", "\014FunctionFour"} };
XLOPER xlFuncParams[N_FUNCTION_REGISTRATION_PARAMETERS+1];
LPXLOPER ppxlFuncParams[N_FUNCTION_REGISTRATION_PARAMETERS+1];
Excel4(xlGetName, (ppxlFuncParams[0] = &xlFuncParams[0]), 0);
for(int i = 0; i < N_FUNCTIONS; i++) {
for (int j = 1; j <= N_FUNCTION_REGISTRATION_PARAMETERS; j++) {
xlFuncParams[j].xltype = xltypeStr;
xlFuncParams[j].val.str = rgFuncs[i][j-1];
ppxlFuncParams[j] = &xlFuncParams[j];
}
Excel4v(xlfRegister, 0, N_FUNCTION_REGISTRATION_PARAMETERS+1, ppxlFuncParams);
}
Excel4(xlFree, 0, 1, (LPXLOPER)&xlFuncParams[0]);
return 1;
}
extern "C" __declspec(dllexport) LPXLOPER xlAddInManagerInfo(LPXLOPER xAction) {
static XLOPER xInfo;
XLOPER xloCoerceType, xIntAction;
xloCoerceType.xltype = xltypeInt; xloCoerceType.val.w = xltypeInt;
Excel4(xlCoerce, &xIntAction, 2, xAction, (LPXLOPER)&xloCoerceType);
if( xIntAction.xltype == xltypeInt && xIntAction.val.w == 1) {
xInfo.xltype = xltypeStr;
xInfo.val.str = "\010ExcelBug";
} else {
xInfo.xltype = xltypeErr;
xInfo.val.err = xlerrValue;
}
return (LPXLOPER)&xInfo;
}
LPXLOPER XLReturn(const double* pdData, const int nData, bool bRow=false) {
static XLOPER xlDLLResult;
static int nAllocated = 0;
if( nAllocated==0 ) {
xlDLLResult.xltype = xltypeMulti;
nAllocated=max(nData,2);
xlDLLResult.val.array.lparray = new XLOPER[nAllocated];
} else if( nAllocated < nData ) {
delete [] xlDLLResult.val.array.lparray;
nAllocated = nData;
xlDLLResult.val.array.lparray = new XLOPER[nAllocated];
}
for(int i = 0; i < nData; ++i) {
xlDLLResult.val.array.lparray[i].xltype = xltypeNum;
xlDLLResult.val.array.lparray[i].val.num = pdData[i];
}
xlDLLResult.val.array.rows = (WORD)(bRow? 1 : nData );
xlDLLResult.val.array.columns = (WORD)(bRow? nData : 1 );
return (LPXLOPER) &xlDLLResult;
}
extern "C" __declspec(dllexport) LPXLOPER FunctionOne( LPXLOPER ) {
double dData = 41144.;
return XLReturn(&dData, 1);
}
extern "C" __declspec(dllexport) LPXLOPER FunctionTwo( LPXLOPER ) {
const double pdData[2] = {41145., 41176.};
return XLReturn(pdData, 2);
}
extern "C" __declspec(dllexport) LPXLOPER FunctionFour( double, LPXLOPER ) {
const double pdData[2] = {41145., -0.01345212};
return XLReturn(pdData, 2, true);
}
The spreadsheet that demonstrates the problem is in the package pointed to by the link above.
Has anyone seen similar behaviour (yes, the description is very vague, so I realize its hard to say…)?
This has been confirmed by Microsoft as a bug in Excel 2003. It occurs in more circumstances that my simple example. My simple example required the unloading and reloading of the addin, but I have had the error occur is circumstances where I was simply doing range calcs. It always seems to occur when one attempts a sheet-calc (shift-F9) after a range-calc. They are not willing to fix it. I am amazed I have not seen any other complaints about this bug.