多年来，我们一直受到客户偶尔报告关于在我们的应用程序启动时出现的非描述性错误消息“无法设置分配”的困扰。到目前为止，我们从未能够在我们自己的测试环境中重现该问题。我现在已经没有尝试追查此事的想法了。以下是随时间积累的一系列观察结果：
- 错误消息文本为“无法设置分配”（注意没有标点符号）。
- 窗口标题只是读取“错误”（或本地化等效项）。
- 无论操作系统区域设置如何，“无法设置分配”文本始终为英文。
到目前为止，我无法找到包含消息文本的 DLL 或 EXE。
谷歌充斥着各种不同产品的此错误报告- 但没有解决方案。
到目前为止，我可以确定的受影响产品之间唯一统一的方面是它们似乎都以加载到第三方进程（例如 Visual Studio 的插件或 Windows Explorer shell 扩展）的 DLL 的形式出现。
我们的应用程序实际上是一个用于 MS Outlook 的共享软件 COM 插件，用 Delphi 编写（即本机代码 - 没有 .NET）。
在我们的案例中，主要嫌疑人是我们正在使用的第三方许可包装器，它可以即时解密和解压缩我们的 DLL 到内存中。显然，我不能简单地将我们应用程序的未受保护版本提供给受影响的客户来验证这种怀疑。也许被报告的其他供应商正在使用类似的产品。
许可供应商提供给我们的保护包装的调试版本没有产生任何结果：日志文件看起来与未发生错误的会话完全相同。显然，“内部”DLL 被解密并解压缩，但由于某种原因仍然无法被主机进程加载。
通过创建一个未受保护的“加载器”DLL，我们能够查明在调用之后某处发生的错误，该
LoadLibrary调用应该将我们的 DLL 加载到内存中。我们自己的代码（不受保护的加载程序和受保护的“核心”-DLL）中的大量日志记录和全局异常挂钩根本没有产生任何结果。该错误显然是在其他地方提出的。
我之前的这个问题中描述的问题很可能是由同一问题引起的。这是在我们创建不受保护的加载程序存根之前。
该错误仅发生在大约 1-2% 的客户身上——而通常任何受影响客户现场的所有安装都会受到同样的影响。
- 有时错误会在我们发布新版本后消失，但通常会在几周或几个月后再次出现。
- 一旦错误开始在机器上发生，它就会始终如一地发生。
通过远程访问（例如 VNC、RDP、TeamViewer 等）连接到受影响的机器时，该错误永远不会发生，并且受影响的客户都不在我们的旅行距离内，所以我们只需要查看日志文件和“eye-证人报告”。
一位客户报告说错误消息对话框显然是非模态的，即他能够简单地将对话框移到一边并继续使用应用程序（减去我们的 DLL 将提供的功能）。不确定这是否在所有其他事件中也普遍适用。
在某些情况下，客户可以通过禁用或卸载与我们自己的产品共享主机应用程序的其他供应商的其他插件来永久摆脱错误。
到目前为止，该错误已在 Windows XP、Vista 和 7 上观察到。
在过去的几周里，我们收到了大量来自 Outlook 2003 / Windows 7 用户的报告。最近的 Windows/Office 更新会使情况变得更糟吗？
有没有人有这个错误的经验？
或者有更多的想法来调查这个？