InnoSetup与Delphi DLL之间的内存管理问题

情况：

一个DLL，用于：

是用Delphi XE3 32位编写和编译的 导出显示模式VCL表单的函数： 函数编辑选项SANIFILENAME:PAnsiChar；ALCID:Integer:Boolean；stdcall

也是一个COM服务器

使用InnoSetup 5.5.4创建的安装程序： 通过外部接口导入所述DLL函数EditOptions@files：mydll.dll stdcall'-指令，并在需要时调用它 在通过Inno实用程序函数UnloadDLL注册COM服务器之前，显式卸载DLL 问题:

什么时候 Windows使用的主题不是Classic 安装期间将显示DLL中的模式对话框 卸载DLL时，安装程序将挂起 不会显示任何错误消息 日志表明没有运行时异常 请注意，为了保持简短，我故意省略了一些更特殊细节的解释，例如，为什么我要显式卸载DLL，或者为什么COM服务器需要自定义导出。如果您认为这些细节相关且应添加，请告知我

为了进一步分析这一点，我创建了一个调用DLL函数的虚拟主机EXE，以便在调试器中更轻松地运行整个过程。这样做会导致在TUxThemeStyle.UnloadThemeData中调用CloseThemeData的行中引发AV。当直接在该行上放置断点并从停止点向前移动时，实际上最终会出现太多连续异常错误。我只能在为主机EXE启用运行时主题时再现错误

回顾我们的git历史，似乎自从我们从Delphi 2010切换到XE3之后，这个问题就存在了。不幸的是，安装程序不是我们常规测试套件的一部分，所以这只是在实际版本的工作接近尾声时出现的，因为DLL导出的存在完全是为了安装程序的利益

你知道这是什么原因吗？这真的是与主题相关的吗？我在这个项目中没有自定义的与主题相关的代码，或者这只是完全由其他地方引起的内存损坏的症状？例如，我曾经在主题分解代码中以AVs的形式出现过一个错误，但在这种情况下，它实际上是由初始化部分的匿名方法引用泄漏引起的

更新：我一直在努力制作一个简化的示例项目来单独演示这个问题，但到目前为止运气不佳。不过，我已经设法缩小了一些范围。首先，以下是关于代码的更多事实：

我显示的对话框是TForm的三级后代。祖先们完成了几件事： TAppModalDialog实现了一个特殊的构造函数CreateOnTop，确保它显示为当前进程中最顶层的窗口。该项目是一个插件，加载到多窗口的第三方主机中，不幸的是，这些主机没有将其窗口句柄作为模式父级进行通信。它通过操纵全局应用程序句柄。 TTabbedDialog是一个基于接口的框架的一部分，该框架允许通过工厂模式注册页面的实际TFrame子体-在运行时，表单将在TPageControl中动态创建TTabSheets，并实例化已注册的页面框架并将其作为其父级 我用一个虚拟对话框代替了对实际对话框的调用，逐渐地通过继承链从一个空白的TForm到我的TAppModalDialog，最后到我的TTabbedDialog类。问题只在最后一级才开始出现。我还注释掉了项目中的所有页面注册，因此对话框中出现了一个空页面控件，这排除了任何页面中的代码是问题的原因。然后，我注释掉了TTabbedDialog类本身例程中的所有代码和数据成员，只留下空的方法体来满足接口实现要求，TPageControl组件以及两个空的TimageList和一个TballonHint组件->错误仍然发生

然后，我将对虚拟对话框的调用复制到一个新的DLL项目中，该项目只包含这个和选项卡式对话框框架。如果我将该DLL加载到我的虚拟主机EXE中，问题就不会再发生了。。。叹息

因此，我的怀疑仍然是，一定有某种内存损坏完全发生在其他地方，我看到的错误只是一种症状。所以真正的问题是我如何才能最终弄清真相

---

现在，我将继续注释/删除生产DLL中的位…

我想知道您为什么使用sharemem。我认为你不应该这样做。看到导出函数的实现也会很好。@David：实际上，这主要是通过多次尝试和错误解决Sisulizer生产的i18n DLL中ResourceString的问题而获得的一种解决方法。然而，我只是在没有sharedmem的情况下再次尝试，问题描述如下

---

re似乎不受此影响，可能应该在发布之前进行测试，这样我就可以完全忽略这个细节。至于导出的函数：你是指实际实现还是只是签名？不幸的是，实现并不完全直接：我显示的对话框是一个自定义的TForm子体，上面有TPageControl，它在运行时通过注册机制动态加载页面……从签名开始。@David:Done。不过没什么特别的。。。