What is the "Cannot set allocations" error, who emits it and what can I do about it?

Question

We've been plagued for several years by occasional reports from customers about a non-descript error message "Cannot set allocations" that appears on startup of our app. We have never been able to reproduce the problem in our own test environments so far. I have now run out of ideas for attempting to track this down. Here's a collection of observations that have accumulated over time:

• Error message text reads "Cannot set allocations" (note absence of punctuation).
• The window title simply reads "Error" (or the localized equivalent).
• The "Cannot set allocations" text is always in English regardless of OS locale.

• I have so far not been able to locate the DLL or EXE containing the message text.

• Google is chock full of reports of this error for a variety of different products - but no solutions.

• The only unifying aspect between the affected products I could make out so far was that they all appear to come in the form of DLLs that load into third-party processes (such as addins for Visual Studio or Windows Explorer shell extensions).

• Our app is actually a shareware COM-addin for MS Outlook, written in Delphi (i.e. native code - no .NET).

• The prime suspect in our case is the third-party licensing wrapper that we're using which decrypts and uncompresses our DLL into memory on the fly. Obviously I couldn't simply give an unprotected version of our app to the affected customers to verify this suspicion. Maybe the other vendors that this has been reported against are using similar products.

• Debug versions of the protection wrapper supplied to us by the licensing vendor yielded no results: The log files looked exactly the same as from sessions where the error did not occur. Apparently the "inner" DLL gets decrypted and uncompressed all right but for some reason still fails to get loaded by the host process.

• By creating an unprotected "loader" DLL we have been able to pinpoint the occurrence of the error somewhere behind the LoadLibrary call that is supposed to load our DLL into memory.

• Extensive logging and global exception hooks in our own code (both the unprotected loader and the protected "core"-DLL) yielded no results at all. The error is obviously raised somewhere else.

• The problem described in this earlier question of mine was very probably prompted by the same issue. This was before we created the unprotected loader stub.

• The error only occurs at about 1-2% of our customers - whereas typically all installations at any affected customer's site are affected the same.

• Sometimes the error goes away after we release a new version but often it will come back again after a couple of weeks or months.
• Once the error has started to occur on a machine it does so consistently.

• The error never occurs while connected to the affected machine via remote access (e.g. VNC, RDP, TeamViewer, etc.) and none of the affected customers are within travel distance from us so all we have to go by is log files and "eye-witness reports".

• One customer reported that the error message dialog apparently was non-modal, i.e. he was able to simply move the dialog box to the side and continue working with the application (minus the functionality that our DLL would have provided). Not sure whether this is universally true in all other occurrences, too.

• In some cases customers have been able to permanently rid themselves of the error by disabling or uninstalling other addins from other vendors that were sharing the host application with our own product.

• The error has so far been observed on Windows XP, Vista and 7.

• During the last few weeks we had a surge of reports from Outlook 2003 / Windows 7 users. Could the situation have been made worse by a recent Windows/Office-update?

Does anyone have any experience with this error at all?

Or any more ideas for investigating this?

Answer 1

If you have a customer who is willing to work with you a bit, it might shed some light on the situation to get a crash dump (e.g., with ADPlus or maybe simpler with Sysinternals' ProcDump) when the error message is showing. That would show what modules are loaded and possibly the callstack (if it is from a message box at the time of the error as opposed to one that is catching an exception after the problem).

Answer 2

This is going to be pure guess-work, but it sounds like maybe your third-party licensing software is trying to load your DLL at a particular location in memory, which - on these failing systems - happens to already be occupied by something else, perhaps a global hook DLL.