none
MAPIAllocateBuffer fails with error 80040605 (MAPI_E_NOT_INITIALIZED) ? RRS feed

  • Question

  • I have a COM Add-in for Outlook 2010 and on one person's computer, when I call MAPIAllocateBuffer (even for a very small buffer) it returns an error code of 80040605.  Apparently it is saying MAPI is not initialized.  I am calling this from within a mail item.

    When I test it on my system it works fine.  This user can reproduce the problem consistently though.

    Here is some sample/test code:

    	HRESULT hr;
    	LPADRLIST pAdrListTest = NULL;
    	int nSize = CbNewADRLIST(1);
    	hr = MAPIAllocateBuffer(nSize, (void **)&pAdrListTest);
    	if(1)
    	{
    		char szErr[MAX_EMAIL_LENGTH + 50];
    		if(FAILED(hr)) sprintf_s(szErr, _countof(szErr), "TEST: Failed to allocate ADRLIST: %X, %d", hr, nSize);
    		else sprintf_s(szErr, _countof(szErr), "TEST: Succeeded to allocate ADRLIST: %X, %d", hr, nSize);
    		::MessageBox(m_hWndParent, szErr, szAppName, MB_OK | MB_ICONEXCLAMATION);
    	}
    	if(pAdrListTest != NULL) MAPIFreeBuffer(pAdrListTest);
    

    Will return "TEST: Failed to allocate ADRLIST: 80040605, 16".

    Any ideas on why this might happen, or what I could do to fix it?

    Thanks,

    Mark

    Beiley Software

    Saturday, March 10, 2012 12:17 AM

Answers

  • Do not statically link to any mapi dlls. Always use LoadLibrary.

    Generally, you will need to jump through a few hoops to figure out the location of the dll (which may depend on the locale in the older versions of Outlook). But since you are running in the outlook.exe process space, it already loaded msmapi32.dll.

    Use GetModule("msmapi342.dll"), then GetModuleFileName, then LoadLibrary.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.2 is now available!

    • Marked as answer by Mark Beiley Wednesday, March 14, 2012 10:05 PM
    Monday, March 12, 2012 4:48 AM

All replies

  • Are you calling that code on a secondary thread?

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.2 is now available!

    Sunday, March 11, 2012 8:12 AM
  • Hi Dmitry,

    Thanks for the reply.  No, it is not running in a secondary thread.  Everything in my add-in runs in a single thread.

    It fails the very first time I call MAPIAllocateBuffer().  I've experimented with moving the allocation attempt to be the very first thing I do, and no matter when/where I attempt it, it fails with the same error code.

    Any other thoughts/ideas?

    Thanks,

    Mark

    Beiley Software

    Sunday, March 11, 2012 5:23 PM
  • How do you locate and load msmapi32.dll?


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.2 is now available!

    Monday, March 12, 2012 3:00 AM
  • Hi Dmitry,

    I don't believe I am specifically locating/loading that DLL...  Should I be?  My project's properties have the linker input settings set to link to mapi32.lib, but I have no specific mention of msmapi32.dll anywhere in my code.  I have a C++ ATL COM add-in if that makes any difference.  I do successfully get a pointer to the MAPI object before I try the allocation.  Here is that code:

    CMailItem::CMailItem(Outlook::_MailItem* pParent)
    {
    	m_pParent = pParent;
    	try
    	{
    		m_pMAPIMessage = NULL;
    
    		HRESULT hr = m_pParent->get_MAPIOBJECT(&m_pMAPIMessage);
    		if(FAILED(hr)) m_pMAPIMessage = NULL;
    	}
    	catch(...){}
    }

    I have verified that m_pMAPIMessage is not NULL.  Everything seems to work fine on my system, and most customers, but I do have one customer who consistently gets this failure when I call MAPIAllocateBuffer().  Maybe I'm not initializing something right, and I'm just getting lucky on my machine, I'm not sure...

    Thanks for your help,

    Mark

    Beiley Software

    Monday, March 12, 2012 3:51 AM
  • Maybe the problem is that I'm never calling MAPIInitialize()?  I assume that because Outlook already provides me a pointer to the MAPI object that it is initialized.  Maybe I need to call MAPIInitialize() myself also for some reason?

    Thanks,

    Mark

    Monday, March 12, 2012 4:13 AM
  • Do not statically link to any mapi dlls. Always use LoadLibrary.

    Generally, you will need to jump through a few hoops to figure out the location of the dll (which may depend on the locale in the older versions of Outlook). But since you are running in the outlook.exe process space, it already loaded msmapi32.dll.

    Use GetModule("msmapi342.dll"), then GetModuleFileName, then LoadLibrary.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.2 is now available!

    • Marked as answer by Mark Beiley Wednesday, March 14, 2012 10:05 PM
    Monday, March 12, 2012 4:48 AM
  • If you are running on the main Outlook thread in your COM add-in, MAPIInitialize would be already called, but it won't hurt if you do that again.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.2 is now available!

    Monday, March 12, 2012 4:49 AM
  • Have a look at the MFCMAPI source code to see how the location of the MAPI dlls is determined.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.2 is now available!

    Monday, March 12, 2012 4:50 AM
  • Thanks very much Dmitry for your help.  I will work on this and report back what I find.

    Mark

    Beiley Software

    Monday, March 12, 2012 9:30 PM
  • I've made this change to use GetModuleHandle()/GetModuleFilename/LoadLibrary()/GetProcAddress() instead of statically linking to mapi32.dll.  Unfortunately the customer who was having the problem seems to have lost interest, so I can't verify whether or not this fixed this particular problem.  I'm glad to have made this improvement though, and am guessing this probably was the reason for the problem.  Thanks very much for your help Dmitry.

    Mark

    Beiley Software

    Wednesday, March 14, 2012 10:04 PM