MFC app Assert fail at CRecentFileList::Add on Command line FileOpen

Question

I'm using VS2010 and Windows 7, and my app is SDI shared DLL, upgraded from VC6. After installing my application, if the user double-clicks the registered file type, the application crashes at the MFC function:

void CRecentFileList::Add(LPCTSTR lpszPathName, LPCTSTR lpszAppID)
{
 // ...
#if (WINVER >= 0x0601)
// ...
#ifdef UNICODE
// ...
#endif
ENSURE(SUCCEEDED(hr));    // Crash here: "hr = 0x800401f0 CoInitialize has not been called."

This is called from the InitInstance() function:

// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);

//CString str = cmdInfo.m_strFileName + '\n';
//MessageBox(NULL,str, "MyApp", MB_OK|MB_ICONWARNING);

// Dispatch commands specified on the command line
if (!ProcessShellCommand(cmdInfo))
    return FALSE;

The user's chosen file is correctly passed through (as I checked with the MessageBox).

The hr = 0x800401f0 seems to be a COM problem (here), but I'm not using COM or ATL. The assertion is the same as this, but from a different cause. The Germans had the same problem as me (here), but I can't understand the google translation (here)!! I don't think it's a WINVER issue (here) and I don't want to parse my own stuff (like this), just have the application open when a user double clicks a file.

Thanks for any help you can offer :)

The system might be using COM and ATL, even if you don't do that directly. The first link hints on initialization being different for VC6 and VC10. I'd create a new application and compare the generated initialization code to the one you have. Bet there are some new calls! — Bo Persson
There sure are Bo! But I tried that: I generated an empty MFC project, took the new/different code bits and applied them to my main app - no joy. I don't want to have to move a 20k line app to an empty MFC project because of this! Thanks for the help. — Colin
Ok, I see. I have never gone directly from VC6 to VC10, but taken all the intermediate steps and noted that there were changes most of the time. — Bo Persson
I held out as long as I could ;) Perhaps the solution is to move it all to a newly generated skeleton MFC app. I could use new features then too...Thx — Colin

Cody Gray Cody Gray · Accepted Answer · 2011-07-09T10:07:46

The comment you inserted in your code contains the answer:

// Crash here: "hr = 0x800401f0 CoInitialize has not been called."

The HRESULT value is telling you that you need to call the CoInitialize function in order to initialize the COM library for your application's thread.

Of course, the message is a little bit outdated. As you'll see in the above-linked documentation, all new applications should call the CoInitializeEx function instead. No worries, though: it does essentially the same thing as its older brother.

As the "Remarks" section of the documentation indicates:

CoInitializeEx must be called at least once, and is usually called only once, for each thread that uses the COM library. [. . . ] You need to initialize the COM library on a thread before you call any of the library functions except CoGetMalloc, to get a pointer to the standard allocator, and the memory allocation functions. Otherwise, the COM function will return CO_E_NOTINITIALIZED.

You say that you're not using COM, but this is incorrect. You may not be using it explicitly, but Windows and the MFC framework are definitely using it "behind the scenes". All of the file type registration functions rely on COM. The skeleton code produced by the MFC project wizard in Visual Studio 2010 would have automatically inserted the appropriate COM registration code, but since you upgraded an existing project from VC++ 6, you appear to be missing this vital step.

In MFC, the AfxOleInit function also initializes COM for the current apartment of the calling app, just as the OleInitialize function does internally. Make sure that your overridden InitInstance function contains a call to one of these functions.

For example, in a fresh new MFC project created by the VS 2010 wizard, the InitInstance function looks something like this:

BOOL CTestApp::InitInstance()
{
    // InitCommonControlsEx() is required on Windows XP if an application
    // manifest specifies use of ComCtl32.dll version 6 or later to enable
    // visual styles.  Otherwise, any window creation will fail.
    INITCOMMONCONTROLSEX InitCtrls;
    InitCtrls.dwSize = sizeof(InitCtrls);
    // Set this to include all the common control classes you want to use
    // in your application.
    InitCtrls.dwICC = ICC_WIN95_CLASSES;
    InitCommonControlsEx(&InitCtrls);

    CWinApp::InitInstance();

    // Initialize OLE libraries
    if (!AfxOleInit())                   // ** MAKE SURE THAT YOU CALL THIS!! **
    {
        AfxMessageBox(IDP_OLE_INIT_FAILED);
        return FALSE;
    }

    AfxEnableControlContainer();

    // . . . 
    // a bunch more boring initialization stuff...

    // The one and only window has been initialized, so show and update it
    pFrame->ShowWindow(SW_SHOW);
    pFrame->UpdateWindow();
    return TRUE;
}

MFC app Assert fail at CRecentFileList::Add on Command line FileOpen

1 Answers