2

Windows Installer 自我修复可能会给开发人员、系统管理员和最终用户带来问题。如果您的 MSI 经验有限，则可能很难找到解决方案。

这是一个问答式的答案，旨在作为解决自我修复问题的清单。以下是一些常见的问题场景：

  • 每当您在工作站上启动应用程序时，可能会发生重复的 Windows Installer 自我修复。如何解决这个问题，或者如何禁用组件以使其不再发生？
  • 可能会部署 WiX 安装程序，并且每当您尝试启动应用程序时，您都会看到重复的 Windows 安装程序自我修复。
  • 在启用或安装 MS Office 插件时，您会在一个或多个 MS Office 应用程序的应用程序启动时体验到持续的 Windows Installer 自我修复。
  • 在 VB6 或 VBA 中处理遗留解决方案时，当您启动主要的开发人员 IDE 时，会针对不相关的产品进行自我修复。
  • 在 Outlook、Excel 或 Word 或类似应用程序中打开表单时，会针对其他供应商的不相关产品启动自我修复。

关键字：Windows Installer 意外启动。MSI 显示异常。Windows Installer 每次都会出现。打开应用程序启动 Windows 安装程序。Windows 安装程序自我修复。包裹如何自我修复。MSI 自我修复最佳实践。Windows 安装程序修复。自我修复。禁用 Windows 安装程序。Windows Installer 反复运行。应用程序快捷方式改为启动安装程序。Windows 安装程序意外出现。

4

3 回答 3

8

自我修复，简单而简短的说明：如果我删除文件，为什么 MSI 安装程序会重新配置？

WiX / MSI 文件的具体设计建议

我一直在尝试写关于为开发人员重复 MSI 自我修复的文章，但最终写得太详细了。这是我的最后一次尝试：关于在 WiX/MSI 文件中不应该做什么的具体设计建议。

下面的答案提供了一个用于解决任何自我修复方案的清单- 来自任何供应商或来源，而不仅仅是您自己的。检查上面链接的答案，了解您自己的 MSI 封装设计问题。

“短版” - 自我修复清单

为了永久且可靠地为每个人修复自我修复问题，开发人员和设置开发人员必须参与其中，因为真正的修复必须在供应商级别进行。

如果您在企业环境中，质量差的应用程序重新打包也会导致自我修复问题，您应该让您的应用程序打包人员确定问题是否来自供应商。

系统管理员必须知道他们在看什么，并且当没有可用的修复程序时，使用各种变通方法来处理野外的问题。甚至最终用户也可以自己尝试一些简单的解决方法（参见第 5 节）。

自修复问题的本质：

  • 大多数自我修复问题与 COM 相关，供应商和开发人员有两个通用修复：1 ) 使用通常通过合并模块部署的正确部署的共享 COM 库，或 2) 使用无注册 COM 来“屏蔽”您的应用程序自修复和兼容性问题。
    • 您的设置开发人员可以实施合并模块修复，开发人员必须进行测试。合并模块是用于共享文件的标准化共享部署库。
    • 根据我的经验，无注册 COM仅适用于开发人员参与。如果开发人员需要使用特定版本的 COM 文件（无论出于何种原因），此选项尤其重要。详情见下文第 5.4 节。
  • 除了 COM，您还可以通过让安装程序开发人员在您的MSI 安装程序中注册文件和MIME 关联以及命令动词来导致自我修复问题。谨慎使用，并确保您的文件/MIME 关联是唯一的。
  • 最后，您可以通过两个已安装的 MSI 文件之间的任何文件或注册表冲突导致自我修复。他们“错误地共享资源”并将其视为自己的资源 - 与之抗争直到冲突解决。
  • 一些自我修复问题根本不是由供应商应用程序或设置中的错误引起的，而是由相关计算机环境中的外部因素引起的，例如修补用户、脚本、病毒、防病毒或安全软件的干扰。有关详细信息，请参阅第 3 节。

处理问题应用程序的快速选项

如果您确定您看到的自我修复仅由 MSI 引起（而不是由下面前几节中描述的其他外部原因引起），也许可以直接跳到第 5 节以获取建议的修复和解决方法的列表。

第 5 节中提出的大多数“解决方案”实际上主要是系统管理员的技巧，它们不能解决根本问题——如上所述，真正的解决方案必须来自供应商。例外是“5.4：无注册COM”，它实际上可以帮助开发人员“保护”他们的应用程序免受自修复问题。

如果您的盒子没有管理员权限，建议您尝试“解决方案” 5.2、5.3或5.1 （5.1通常需要管理员权限才能尝试，但并不复杂）。这些是“快速解决方法”，其他涉及更多。如果这些解决方法不起作用，请让您的管理员阅读其他建议。

了解 Windows Installer 自我修复

我之前已经详细写过这个问题，但它过于关注理解问题，而不是真正找到可接受的解决方案。您可以在此处阅读自修复问题的完整说明：如何确定导致 Windows Installer 重复自修复的原因？.

修复 Windows Installer 自我修复问题

要真正修复重复和无休止的自我修复，您可以尝试以下第 5 节中的建议 - 按复杂性和难度递增的顺序排列。在这样做之前，您应该验证自我修复问题的真正根源是什么。它可能不是由 MSI 文件引起的，而是由其他外部原因引起的（例如脚本或用户删除文件或防病毒阻止文件）。

如果问题确实与 MSI 相关，您可以尝试禁用广告的快捷方式和COM 插件，使用无注册 COM，从应用程序供应商处获得帮助，卸载有问题的应用程序，虚拟化包或完全破解缓存的 MSI 数据库和注册表（不推荐，只有在专家帮助下才有可能）。这完全取决于您的情况。如果脚本等外部原因出现故障，则必须消除这种干扰。请参阅下面的详细信息 - 只需按照清单进行操作。

解决问题的第一步是确定问题确实存在于您的平台上，然后首先确定哪些应用程序触发了自我修复：

1.验证您的环境中确实存在问题。

  • 通常总是可以找出导致有问题的自我修复的原因，并且有几种可行的解决方法可用于处理该问题。然而，并不总是能够找到一个好的、永久的修复（没有供应商的帮助 - 如下所述）。
    • 因此，如果您是一名系统管理员，试图为您的自我修复问题找到解决方案，也许要确保在不止一台计算机上发现问题 - 特别是如果在开发人员、QA甚至测试中发现问题时电脑。
    • 如果您只在一台计算机上看到自我修复问题，另一种方法可能是重建有问题的计算机。有效地消除而不是“解决”问题。但是，您可能会再次看到该问题的风险相对较高。如果你问我，不要重建，这不是解决方案 - 但我猜在现实世界中往往会做些什么。
  • 请注意，安装速度缓慢且不断被用户中止的AD 宣传的 MSI 安装可能“看起来像”桌面支持的自我修复问题，但这是预期的 MSI 行为。允许安装完成一次（可以更改安装程序进度条以禁用取消按钮 - 类似于只有进度条，没有取消按钮，最后没有模式对话框）。msiexec.exe /I "MyApp.msi" /QB-!

2.找出自我修复的罪魁祸首。

  • 单个应用程序可能会自行导致问题，但通常至少有两个应用程序发生冲突（它们错误地共享某些资源）。
  • 自修复的触发器通常可以在发生自修复的系统上的事件查看器中找到。按照以下步骤打开事件查看器：
    • 右键单击“我的电脑”
    • 点击管理
    • 如果收到 UAC 提示，请单击继续
    • 转到事件查看器部分，然后检查 Windows 日志
  • 通过查看事件日志的“应用程序部分”，在Windows 事件日志中识别有问题的应用程序，您应该会发现来自ID 为 1001和1004的事件源“ MsiInstaller ”的警告。

3.验证外部非 MSI 原因不是导致问题的原因

  • 手动或自动删除文件或注册表设置的任何操作都可以触发 MSI 自我修复。尤其是当您在用户配置文件或注册表的 HKCU 部分中删除内容时弄乱了。
    • 在大多数情况下，此类触发器只会导致一次自我修复运行，然后问题就解决了（这就是自我修复应该如何工作并帮助用户）。允许自我修复运行一次，然后再次启动应用程序以测试问题是否消失。它应该是，并且您的应用程序应该从现在开始正确启动。
    • 特殊情况：具有讽刺意味的是，您有时可以通过重命名其 HKCU 应用程序密钥（在注册表的用户部分中）来修复损坏的应用程序，以实际强制自我修复运行并在用户配置文件中安装应用程序的默认数据 - 如果该数据是意外的已删除（这种类型的修复程序通常不适用于终端服务器）。
    • 如果通过自动方式再次删除相同的文件或注册表项并自行修复结果，您必须消除或更新导致它的自动过程并且您的问题得到解决并且您可以停止阅读。如果您自己再次手动删除了该文件，那么您可能会遭受记忆不佳的困扰:-)。
    • 总之，清理脚本、登录脚本、清理应用程序或修补，过度活跃的用户都可能导致这种自我修复。
  • 最后，病毒和防病毒软件（和其他安全软件）可以阻止对文件的访问并触发永远不会成功的自我修复。
    • 对于受感染的计算机，只需重建计算机。这将节省您的整体时间。
    • 对于防病毒/安全软件问题，请带您的安全人员来解决它。在某些情况下（尤其是误报），他们可能需要联系供应商。
    • 无论是病毒还是反病毒相关，请检查http://www.virustotal.com上的违规文件，以验证它是否真的是病毒或只是误报（这可能是自我修复的更大问题）。
    • 我个人见过几个防病毒/安全软件相关的自我修复问题，但没有真正的病毒相关问题（到目前为止）。我猜病毒通常感染核心系统文件而不是应用程序文件，并且核心系统文件不是由MSI文件部署的（共享系统文件可能包含在MSI文件中，但不包含核心系统文件）。

4.联系供应商（或您自己的包装部门）。

  • 一旦您确认自我修复问题是基于 MSI 的并且它不是您自己的软件，首先要尝试联系应用程序供应商，看看他们是否有更新的安装程序来消除问题。

  • 尝试此选项很重要，因为所有其他选项都是“解决方法”而不是真正的修复。该问题只能通过更改供应商安装程序以及可能的应用程序可执行文件本身来彻底解决。

    • 修复 1：修复可以简单到让供应商使用适当的共享“合并模块”删除私人安装但全局注册的 COM 文件，以便为每个人正确安装运行时。这些应该将 COM 文件正确安装到共享位置，在这些位置可以全局注册而不会产生副作用。准备好供大家使用。
    • 修复 2：如果供应商声称这是不可能的 - 那么他们应该能够提供正确的免注册 COM 安装，并将正确隔离的 COM 文件安装到主应用程序文件夹。他们还应该注意随时部署任何安全更新。

  • 重要的！：如果供应商要么使用正确的共享合并模块来部署文件，要么使用无注册 COM提供隔离安装，那么问题应该为每个人永久解决。

  • 该问题也可能是由其他问题引起的，但 COM 往往是罪魁祸首。有时清理他们的 MSI 安装程序可以解决其他更模糊的冲突。如果您认识一个优秀的应用程序打包者，他/她应该能够快速识别冲突（并为供应商提供反馈）。
  • 请注意，自我修复也可能是由供应商软件的错误（内部）重新打包引起的。在这种情况下，您可以通过您自己的打包/部署部门提供的更新来修复自己的包（在大多数情况下，他们肯定能够实现这一点）。这实际上是一个非常普遍的问题。

5.选择“解决方法”或修复来处理冲突情况。

  • 如果供应商不提供固定的安装程序包，您需要找到“解决方法”来处理这种情况。有几种选择，在您深入研究过于复杂的情况之前，应该尝试一些“快速解决方法”。以下是一些解决问题的建议，按照难度和复杂程度的递增顺序排列：

    • 5.1：只需卸载罪魁祸首。

      • 最简单的解决方法是找出哪些应用程序触发了自我修复，然后卸载它，如果这对您的环境来说是一个可接受的解决方案（它很少是）。
      • 如果有两个（或更多）应用程序发生冲突并且其中一个很少使用或“可选”，则这是可以接受的。
      • 您可以改为在虚拟机上运行有问题的应用程序（参见第 5.5 节）。对于非常“行为不端”的应用程序，这将是我首选的“修复”。所有问题都应该在没有任何实际调试的情况下消失（这是昂贵的）。
      • 直接卸载是一个至少值得考虑的选项 - 某些软件可能在多个方面存在问题，应该直接拒绝使用。请务必让供应商知道该软件也被拒绝。这可能是让他们认真对待问题的唯一方法。

    • 5.2：删除广告快捷方式。

      • 第一个尝试的 Windows Installer 解决方法是删除“广告快捷方式”（本质上是一种特殊类型的快捷方式，它指向 Windows Installer 应用程序功能，而不是直接指向可执行文件或文件）。阅读 Symantec 的链接文章，了解有关广告快捷方式的详细信息。
        • 请注意，可以在“任何地方”创建快捷方式，包括在“启动”文件夹等特殊文件夹中。此特定位置意味着可以在系统启动时自行触发自我修复（无需用户交互）。
        • 使用MSI 查看器工具并打开系统缓存的 MSI 并检查其快捷方式表以查找所有快捷方式。为了找到所有缓存包的列表，您可以尝试以下答案：如何找到已安装 MSI 设置的产品 G​​UID？（打开“LocalPackage”中指定的包路径）。
      • 然后，您重新创建一个直接指向相关可执行文件的常规快捷方式。这将“绕过”最常见的自我修复触发器（宣传的快捷方式）。在某些情况下，这可以避免整个自我修复问题。值得一试。
      • 请注意，即使这似乎立即起作用，但在您在应用程序中工作时（例如，当您打开特定表单时），自我修复可能仍会重新出现。您需要与一些实际积极使用该应用程序的用户一起“试点”此修复程序，以确保它对于您的环境来说是一个足够好的解决方法。
      • 您也只是消除了问题的症状，导致它的注册表或文件冲突只是被“绕过”或“沉默” - 它仍然存在，但如果应用程序在运行期间没有出现问题，这可能就足够了。
      • 事实上，有一种方法可以在安装任何 MSI 软件包时禁用所有宣传的快捷方式。您设置属性DISABLEADVTSHORTCUTS（以链接中描述的方式之一），然后所有快捷方式将被创建为常规快捷方式，并且它们不会触发自我修复。至少有两个问题：
        • 1)该软件包可以设计为使用自我修复来安装用户配置文件或 HKCU 设置。在这种情况下，这些数据将永远不会按预期添加到系统中，因为自我修复永远不会运行，并且安装实际上是不完整的。
        • 2)不能保证不会发生自我修复——因为它可以由其他广告的入口点触发，例如 COM 调用、文件和 MIME 关联以及命令动词。

    • 5.3：禁用 COM 插件（如果可能）。

      • 如果您的问题与加载项有关（对于 Outlook、Excel、Word 或其他应用程序，如 AutoCAD 或类似应用程序），则没有可调整的快捷方式 - 加载项在其“主机应用程序”启动时加载。
      • 最简单的尝试是在相关应用程序的插件对话框中禁用任何不需要的插件（通常是Outlook、Excel或Word或类似的），看看这是否会使问题消失。在某些情况下，您只是禁用了用户一开始就从未使用过的 COM 插件，问题就已经解决了。
      • 而且，很明显，还要尝试禁用您实际需要的插件，以检查问题是否与其加载有关。如果插件是罪魁祸首，您应该继续检查列表到下一个建议的解决方案（下一个要点）。
      • 我应该重申，首选的解决方案将是供应商的修复（通常它会涉及使插件正确使用最新的、共享的 ActiveX/OCX 控件 - 但其他插件仍然可能触发问题，如果它们是设计也很糟糕。您最终可能会与多个供应商打交道-通常互相指责）。
      • 公平地说，如果您在公司机器上，问题也可能是由糟糕的公司应用程序重新打包引起的。然后，您必须与包装部门打交道以进行修复。

    • 5.4 : 尝试无注册 COM

      • 可以说这个解决方案比虚拟化更复杂（在下一个要点中描述），但我把它放在这里是因为它可能是某些人的首选选项。
      • 无注册 COM是我很少使用的东西，但据说它是一个可行的解决方案：为免注册 COM 生成清单文件。这实质上绕过了注册表并激活了由位于应用程序可执行文件旁边的清单文件控制的 COM 文件的私有副本 - 有效地屏蔽了应用程序免受 COM 注册表干扰（理论上）。“一切都发生在同一个文件夹中”。
      • 您的内部包装部门也许可以使用它来处理“困难的供应商包”以“隔离”他们的问题。但是，如果没有原始解决方案开发人员提供的一些额外的应用程序调整，我不相信无注册 COM 将正常工作，但我缺乏经验数据来支持它。如果它是具有可用源的内部应用程序，请对其进行测试（并让我们知道）。
      • 我对这种方法的主要问题是，如果您不确保自己更新隔离的组件，它会打开潜在的安全漏洞（Microsoft 永远不会修补的 COM 文件的私有副本）。更新也可能会导致大量的清单重写工作（但这些旧的 COM 文件是否已经更新了？）
      • 请注意，无需注册的 COM，至少在理论上，可用于所有与 COM 相关的冲突，无论它们是 VB6 可执行文件、使用 COM 的 VC++ 应用程序等......老实说，我不确定它是否适用于（办公室） COM 插件 (dll) 和 VBA 表单。
      • 这是关于无注册 COM 的更好的 MSDN 文章之一）：https ://msdn.microsoft.com/en-us/library/ms973913.aspx （甚至还有一个可下载的 MSI 示例 - 其中具有讽刺意味的是，它似乎在启动时触发了我的错误）。
      • 就个人而言，我可能宁愿尝试使用 APP-V 的虚拟包，而不是尝试使用无注册 COM（请参阅下一个要点）。
      • 应该重申，而不是“屏蔽”您自己的应用程序 -正确的供应商修复是停止部署在系统范围内错误注册的共享 COM 文件的私有副本，并开始使用适当的合并模块按预期安装它们部署。

    • 5.5：虚拟化（APP-V、虚拟机等）。

      • 除了卸载或禁用组件之外，最简单的解决方法可以说是使用虚拟化来“隔离”冲突的应用程序。如果您仍希望主 SOE（标准操作环境）上的应用程序，您可以尝试使用虚拟部署包 (APP-V)。这是一个基本上按需安装（在启动时）并运行“沙盒”或与系统上的其他应用程序隔离的应用程序。
      • 您还可以通过VMWare或Microsoft Virtual PC等系统使用虚拟机在其自己的操作系统中运行有问题的应用程序。人们在使用虚拟机时通常拥有管理员权限，但在他们的主 SOE 系统（主工作站）上却没有。许多开发人员应用程序使用管理员权限更有效，因此此解决方案在处理开发团队及其需求时可能特别有用。

    • 5.6：Windows 安装程序调整- （仅限专家！）。

      • 如果问题对于您的桌面环境非常严重，并且上述选项都不起作用，您可以尝试在 Windows Installer 级别解决问题。如果插件（或任何其他软件）对于在公司的主要 PC 环境中可用至关重要，那么它可能是值得的。
      • 本质上，您需要做的是从系统缓存的 MSI 和/或注册表中删除违规条目（禁用广告的入口点，如广告的快捷方式、COM 注册、文件关联、MIME 关联或命令动词等）。
        • 这是非常复杂且不好的做法，并且有一些副作用（用于卸载、弹性等......），但这是我所知道的唯一“最后的手段”。
        • 在这些情况下，建议您联系部署/Windows Installer 专家并让他们分析“修复”是否可行。它可以工作，但不要指望奇迹。
        • 如果您坚持自己调试，则需要使用工具来打开系统上缓存的 MSI 文件（例如 Orca、Installshield、Advanced Installer 或类似工具），并且您需要“破解”数据库 - 不推荐。

    • 5.7 : Windows Installer zapping - （不安全！）。

      • 如果您愿意，我将这个“选项”包括在内是为了完整性和“历史目的”。这从来都不是一个好的选择，现在在较新版本的 Windows 上非常不安全。
      • MsiZap.exe 是一个 Microsoft SDK 工具，旨在作为开发人员清理失败的 MSI 安装或卸载的最后手段，它从未打算广泛使用。它允许对任何 MSI 软件包进行完全的“脏注销”。MsiZap.exe现在已弃用、不受支持且使用不安全。仅在一次性虚拟设备上使用，如果有的话。
      • 过去，一个常见的“系统管理员技巧”是使用MsiZap.exe从系统中“删除”整个 Windows 安装程序包。除了使您的系统变得无法治愈之外，它还消除了该应用程序的所有自我修复问题。
      • 运行 MsiZap.exe 后留下的垃圾基本上包括所有内容（实际的 MSI 数据库注册除外）。所有文件，所有注册表项（包括 COM），SharedDll 引用计数器（在重新安装时确实搞砸了），服务，任何东西。您将永远无法正确卸载。在大多数情况下，您将无法安装没有副作用的同一应用程序的升级版本。许多人在尝试安装在脏状态之上时实际上会看到更多的自我修复问题。
      • Rob Mensching，WiX、Orca 和所有 Windows Installer 的创建者有一篇关于 MsiZap 危险的博客文章。MSDN 描述了另一个不好的副作用：当您使用 Msizap.exe 工具从基于 Windows 的计算机上卸载程序时，所有程序更新信息都会被删除

6.总结与结论

  • 第 4 步-联系供应商进行修复-在我看来 是唯一的“真正的修复”。
    • 所有其他提案都试图处理由供应商错误导致的问题，而不是提供持久的解决方案。
    • 现实世界的问题是许多供应商倾向于互相指责，所以你可能不走运。一些做得对的供应商确实会遭受其他人的设计错误。
  • 提案5.1、5.2、5.3是不复杂的“解决方法”。
    • 应该安全地为每个人尝试。
    • 即使没有管理员权限，建议5.2和5.3也应该可以尝试。
  • 提案5.4 -无注册 COM - 是一个相当复杂的潜在“修复”。
    • 可能需要开发人员参与才能找到要“隔离”的所有相关文件。
    • 以我的经验，这种项目最终需要几天的时间才能尝试（即使有专家的帮助）——没有真正保证它最终会奏效。
    • 我从专家那里听到了相互矛盾的事情，有些人成功了，有些人说它失败了。有权访问解决方案源的人似乎成功了。
    • 就我个人而言，我不喜欢它打开的潜在安全漏洞，并且要部署的任何新文件版本都可能意味着新一轮的清单重新创作（我相信）。
    • 然而，有问题的 COM 文件现在太旧了，无论如何他们都不太可能看到对它们进行的任何安全更新。我想这些 COM 对象现在主要用于 .NET 互操作。
  • 提案5.5 -虚拟化- 目前是一个常见的选项，如果在环境中可用，可能应该在 5.4 之前尝试。俗话说，“虚拟化，认真”。
    • 老实说，我不知道（缺乏经验）虚拟化是否适用于（办公室）插件。如果可以确认请更新。
    • 可执行文件绝对可以虚拟化。
  • 提案5.6 - “缓存 MSI 调整” - 是一种“黑客”，如果部署专家正确完成，它可以“足够好”地工作。
    • 有一些“副作用”，特别是对于卸载- 以及“弹性”，但如果操作正确，这些应该是可以管理的。
    • 这是“真实世界”——没有什么是“干净的”。
  • 提案5.7 - “ zapping MSI ” - 是一个不安全的、已弃用的“遗留黑客”。
    • 由于系统的“脏状态”，有几个副作用。
    • 运行 MsiZap.exe 后报告了 MSI 数据库完全损坏。
于 2017-08-16T14:20:09.703 回答
0

由于每次启动应用程序时都会发生这种情况（我假设您允许修复运行完成），最可能的原因是应用程序删除了受 Windows Installer“保护”的内容，例如注册表项或文件。快捷方式启动修复机制以重新安装丢失的项目，MsiInstaller 条目会告诉您它是什么。

一般来说，维修是一件好事，因为它们允许用户在安装的产品损坏时对其进行维修。如果按照设计，有已安装但不需要修复的资源，则在 WiX 中将 Component Id 设置为 null，因为这是防止修复某些文件的记录方法，请参阅此处的 ComponentId 备注：

https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx

于 2017-08-18T19:47:31.153 回答
0

你的包裹里面一定有问题。寻找问题。

  1. 清除事件日志 - 应用程序。

  2. 使用 AdminRigths 以用户身份运行您的应用程序

  3. 应用程序应在自我修复后运行。你可以运行两次，如果没有出现自我修复，当你第二次运行后，这意味着想要在MachinePart中创建条目的组件有问题，如HKLM或Programfiles或Windows文件夹。

  4. 打开您的事件日志并查找带有源 MSIInstaller 的条目。

  5. 带有警告的条目将为您提供有关哪些功能和组件将导致自我修复的信息。

如果您可以在此处向我们展示该警告的日志，我们可以告诉您有关您的问题的更多信息，但一般来说，eventviewer 内部的消息很清楚，并说明缺少什么资源。

于 2017-08-17T14:07:09.717 回答