0

I have an MFC C++ application running on Win7 rebuilt with VS2013. It uses a custom OCX control. On about the 4th call to the OCX the COleDispatchDriver::InvokeHelper method calls Invoke which results an exception 61706 "Insufficient Memory". This app has been built and run successfully for many years on previous version of Visual Studio (not sure which it was originally built with). The call from the application code which generates the exception is: 

m_Sig1.LCDWriteString( 0, 2, 100, 100, 0, 0, 0, "Testing 123" );

I've stepped into this call and through the Invoke about 4 levels deep and get to this call in library dll oledisp2.cpp

void COleDispatchDriver::InvokeHelperV(DISPID dwDispID, WORD wFlags,
    VARTYPE vtRet, void* pvRet, const BYTE* pbParamInfo, va_list argList)
. . .
    // make the call
    SCODE sc = m_lpDispatch->Invoke(dwDispID, IID_NULL, 0, wFlags,
        &dispparams, pvarResult, &excepInfo, &nArgErr);

The status code sc is returned as 0x80020009 which is DISP_E_EXCEPTION which means "An exception occurred" and the exception info is: 

exceptInfo
    wCode = 61706
    bstrSource = "SigPlus"
    bstrDescription = "Insufficient memory to perform operation."
    bstrHelpFile = 0
    scode = 0

I've tried to step into the m_lpDispatch->Invoke call but the debugger is only showing assembly language saying there is no symbol info for the called module which seems strange as it is a member of the same class (or a parent) that the call is from. As I stepped though the InvokeHelper methods I observed that all of the 8 passed parameters are recognized and processed correctly up to the point of calling Invoke(). Not being able to step into Invoke makes it impossible to see where the memory allocation that is causing an "Insufficient Memory" issue.

I've also tried to build with VS2010 and get the same error.

Other things I've tried is switching from static MFC libs to DLL MFC but the results are the same. I still get "Insufficient Memory" error and can't debug with symbols into the Invoke() call.

I've tried to look up the 61706 error for a detailed description from Microsoft but only found this link which wasn't very informative.

JonN
  • 2,498
  • 5
  • 33
  • 49
  • E_OUTOFMEMORY is defined as 0x8007000E. You are getting a DISP_E_EXCEPTION(0x80020009). The question is, what information is in execpInfo! – xMRi Oct 06 '17 at 09:51
  • @xMRi Yes you're correct that the sc error return simply means "An exception has occurred" which is not really useful to resolving the issue. The exception however is wCode=61706 and bstrDescription = "Insufficient memory to perform operation." And I can't see how this should cause an out of memory issue. I tried to find Microsoft doc with detail description of error code 61706 but didn't find much. This link is not helpful https://learn.microsoft.com/en-us/dotnet/visual-basic/misc/out-of-memory-run-time-error – JonN Oct 06 '17 at 23:44
  • But the component can use this return code as it wants. If the programmer decides that this situation (may be because of wrong parameters) should be expressed with the E_OUTOFMEMORY than he is free to do it... So if I have a STDMTHD interface and I return E_OUTOFMEMORY as a HRESULT, the IDispatch interface will react as you describe. So check your component... or ask the company... check the parameters. – xMRi Oct 07 '17 at 06:57
  • The component is a released product of the company I'm working for & been in the field and operational for 10+ years as is the app calling it. I have an old EXE for the app that works fine with the same version of the OCX component that is failing when run with the app recompiled with VS2010 or VS2013. Through some behavior of the recompiled app I know I don't have the exact source that built the released EXE which runs but stepping through the app I encounter the above error which points to the component. But the component I'm using is exactly the same as the working scenario. – JonN Oct 09 '17 at 19:09
  • So from the circumstantial evidence I'm believing that the cause of the exception is in the app calling the OCX control but looking at all the parameters passed they all look valid and I see no reason for the error and at present I am unable to step into the Invoke call in the debugger. Up until your last response I thought the exception was related to the Invoke call itself and not an exception generated by the OCX component. Thinking I need to see if I can debug the OCX control but I'm not sure if I have source for that. – JonN Oct 09 '17 at 19:18
  • If this OCX control has a dual interface you can access it with this interface. Than you can see if the error is related to the interface or to any framework. – xMRi Oct 09 '17 at 19:35
  • Not sure I understand the meaning of "dual interface." The only interface is the API defined by the OCX control and use by the application. – JonN Oct 10 '17 at 01:52

0 Answers0