【问题标题】:Delphi program & Windows 64-bit compatibility issueDelphi 程序和 Windows 64 位兼容性问题
【发布时间】:2011-02-03 11:26:55
【问题描述】:

我有一些客户/候选人抱怨我的程序无法在他们的 Windows 7 64 位版本上运行(通过屏幕截图确认)。错误很奇怪,例如:

在试用版中我是 每当我收到错误消息 点击“标记”“删除”“帮助”。

错误消息是:访问冲突在 模块中的地址 0046C978 \'ideduper.exe.\' 读取地址 00000004

Windows 7 终极版 64 位。 i7 920 @2.67GHz 9gb 或内存

“Mark”、“delete”和“help”只是 TToolbar 上的标准 TToolButton。

另一个示例是无法从 IExtractImage 获取缩略图。

我已经告诉他们尝试兼容模式,但仍然不起作用。

问题是当我在我的计算机上测试它时(我在实际发布之前已经完成了它)在 Windows 7 HP 64 位上运行良好!所以不知道是什么原因造成的

您有什么建议吗?不同的 Windows 软件包(家庭基本版、高级版、终极版等)是否对 32 位 prog 有不同的处理?较新版本的 Delphis(我使用 2006)是否与 64 位 Windows 更兼容?我需要等到 64 位编译器出来吗?

提前致谢

【问题讨论】:

  • (删除了丑陋的评论系列:摘要 - 它可能是编译器问题、硬件问题、操作系统问题或编码问题 - 不分先后)

标签: windows delphi 64-bit compatibility


【解决方案1】:

在我看来,您最好的选择是添加 MadExcept 或 EurekaLog 或与您的应用程序类似的东西,然后将其交给客户再试一次。 MadExcept 将生成带有堆栈跟踪的日志,这将使您更清楚地了解那里发生的事情。

要回答问题的第二部分,32 位 Delphi 程序在 64 位 Windows 7 上运行良好。我认为您更有可能遇到一些内存管理问题,而客户只是偶然发现了它们,而您却没有。使用 FastMM4 追踪这些。

【讨论】:

  • 有没有免费的替代品?
  • @Irwan 您有客户,但不想为 madExcept 付款?你需要开始充电。这样想,如果你能让你的程序变得更好(让它真正运行!),那么从长远来看,你现在可以通过投资一点点赚更多的钱。
  • MadExcept 对于商业用途来说是便宜的,对于非商业用途来说是免费的。您也可以使用 JCLDebug 编写代码,但如果花了一个小时,而且您的时间值得,那又如何?
  • @Irwan:您可以使用 Jedi 库轻松构建一些东西,您只需要 JclDebug 即可生成日志和堆栈跟踪,然后使用 JclException 发送它们。假设您的时间价值如此之少,以至于 E129 的价值超过了几个小时的工作,那么您已经准备好了。
  • 如果不够用,会尝试 JCL 和 madExcept。感谢所有建议!
【解决方案2】:

您的应用程序正在尝试访问无效指针。不断变化的环境可能会暴露出隐藏在他人身上的问题。检查您的应用程序,并使用 FastMM + JCL+JCVL/MadExcept/EurekaLog 获取问题的详细跟踪。一些 Windows API 在 7 位和/或 64 位下可能有一些更严格的调用要求,但我们必须知道您的应用实际调用的是什么。

【讨论】:

  • 您认为哪些 API 具有更严格的调用要求?
  • 在这种情况下,我不知道是否调用了某些 API,这只是关于可以调查什么的一般性建议。
【解决方案3】:

MadExcept 的免费替代品是 JCL Debug 东西。但是,它不太彻底,并且不包括通过电子邮件将堆栈跟踪发送给您的酷对话框,或者作为您可以附加并手动发送电子邮件的文件。

MadExcept 物有所值,并且可免费用于非商业用途。您可以先在自己的 PC 上试用它,观察它的功能,并确保它以您想要的方式运行,然后再购买。

如果购买 Delphi 是值得的(而且确实如此!),那么购买 mad except 是不费吹灰之力的。但是如果你坚持自己滚动,JCLDebug(绝地代码库的一部分)也很不错。

【讨论】:

  • JCL 异常对话框确实包含通过电子邮件发送堆栈跟踪或将其保存到文件的选项。
【解决方案4】:

为他们提供您应用的精简版,看看问题何时消失。我敢打赌这是你的代码,因为我的(数百个)W7/64 客户端从来没有遇到过任何问题。

【讨论】:

    【解决方案5】:

    我愿意打赌这是您的代码中的一个问题。它在您客户的机器上而不是您的机器上失败的原因是您的机器可能启用了默认的数据执行保护 (DEP)(仅对基本的 Windows 程序和服务打开),而您的客户的计算机实际上正在按预期使用 DEP (为所有程序和服务启用)。

    默认设置(与旧版本的 Windows 兼容,如 95/98/ME)允许软件从应为数据段的部分执行代码。更严格的设置不允许这样做,而是引发系统级异常。

    您可以通过查看系统属性来检查两者之间的设置。我现在不在 Win7 机器上,但在 WinXP 上,您可以通过右键单击“我的电脑”,选择“属性”,单击“性能选项”,然后选择“数据执行保护”选项卡。在 Vista/Win7 上使用帮助找到它;搜索数据执行保护。

    正如之前的答案告诉你的那样,解决方案是安装 MadExcept 或 EurekaLog。您还可以在 JCLDebug IIRC 中获得作为 JEDI 一部分的免费版本。我没用过,所以不能亲自担保。不过听说还不错。

    如果您不想走这条路,请在应用的启动部分中的某处设置断点(确保在打开调试信息的情况下进行构建)。运行您的应用程序,直到断点被命中,然后使用 IDE 的 Search->Goto Address(在断点被命中之前禁用)。输入异常对话框中的地址(不是几乎全为零的地址,而是 0046C978 地址,以 $ 为前缀表示它是十六进制),如 $0046C978。您可能最终会在 CPU 窗口中查看汇编代码,但您通常可以挑选出某种类型的 Delphi 代码行,这些代码有时可以为您提供一个开始查找的地方。

    【讨论】:

      【解决方案6】:

      除了前面所有的建议,我再补充一下WOW64下访问Registry和Win32下的区别。如果您的应用程序正在访问注册表以读取或写入某些设置,您应该意识到这一点。首先,看一下 MSDN 中的thisthis 页面。在this 页面上,您将找到 2 个标志,这些标志确定您从 32 位或 64 位应用程序访问注册表的权限。 KEY_WOW64_64KEY 是您应该使用的。

      无论如何,我同意其他人关于使用 madExcept(或任何其他类似工具)能够找到问题的确切原因的观点。

      【讨论】:

        猜你喜欢
        • 2015-08-23
        • 1970-01-01
        • 1970-01-01
        • 2019-08-19
        • 2013-03-12
        • 2015-01-06
        • 2013-10-04
        • 2015-02-17
        • 2019-06-26
        相关资源
        最近更新 更多