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