c# - 使用 C# 的 Windows Update API 找不到任何已安装的更新

Question

我有许多 Windows 7 PC，需要使用 C# 控制台应用程序中的 Windows Update API 使用特定的 Windows 更新进行修补。 API 需要搜索已安装的更新并报告是否已安装，如果没有则执行安装。

在虚拟 PC(Windows 7 Professional Hyper-v 客户端)上进行测试时，我遇到了与目标 PC(Windows 7 Embedded)类似的情况，其中以下代码返回(非常快且没有任何异常)0 个更新。我知道这是错误的。事实上，在我安装 .msu 更新后，它甚至会返回此信息。

代码:

 UpdateSession uSession = new UpdateSession();
 IUpdateSearcher uSearcher = uSession.CreateUpdateSearcher();
 uSearcher.Online = false;
 try
 {
    ISearchResult sResult = uSearcher.Search("IsInstalled=1 And IsHidden=0");
    Console.WriteLine("Found " + sResult.Updates.Count + " updates");
    foreach (IUpdate update in sResult.Updates)
    {
       Console.WriteLine(update.Title);
       if (update.Title.ToLower().Contains("kb123456")) {
        //Update is not required
        ReportInstalled();
        return;
       }
     }
     //If we get here, the update is not installed
     InstallUpdate();
  }
  catch (Exception ex)
  {
    Console.WriteLine("Something went wrong: " + ex.Message);
  }

现在是有趣的部分。如果我从控制面板打开 Windows 更新并单击“检查更新”，它会关闭一段时间，然后返回一堆要安装的更新。此时，如果我运行上述代码，它会按预期工作并报告超过 200 个已安装的更新。

搜索更新的手动过程似乎会启动/重新启动某些服务和/或其他进程，但是，我正在努力弄清楚我需要对系统执行什么操作才能使其进入正确的状态。我希望答案是使用一组参数启动服务 x 或进程 y 的简单情况，但是哪个？

我尝试过但没有改变行为的一些(不是全部)事情:

1. 启动 BITS 服务，重新启动 Windows 更新服务
2. 尝试使用各种开关启动 wuauclt.exe(已记录) 评论中的here)

当机器处于代码正确运行的状态时(在我手动运行 WU 后)，我注意到在运行上述代码时进程 wuauclt.exe 似乎启动了。当它处于目标状态时(在我手动运行 WU 之前)，wuauclt.exe 不会启动，并且我无法手动启动它，我怀疑这是一个很大的线索。

另一条线索是我手动运行 Windows 更新之前的状态。在控制面板 Windows 更新中如下所示:

运行 WU 并通过该方法安装更新后，机器处于代码按预期运行的状态，WU 如下所示:

总而言之，我需要此过程来自动安装更新。如果我检测到 0 个已安装的更新，我就知道机器处于特定状态，因此我需要启动/重新启动一些进程和服务(以编程方式)，以使机器在运行我的代码之前进入正确的状态。知道要运行/重新启动什么是这个问题的本质。

Answer 1

由于这个问题目前没有答案(尽管综合评论大多给出了答案)，因此这里发生的情况如下:

这是一种非常常见的方法来检查“我是否拥有使我的程序成功运行所需的补丁？”，并且它存在短期和长期问题。

短期问题:

搜索代码正在执行脱机扫描(它将 IUpdateSearcher::Online 设置为 false)。这是加快搜索速度的常见策略。问题是它只处理上次在线扫描期间可用的更新。如果计算机很长时间没有进行在线扫描，那么结果就会过时。如果自上次在线扫描以来计算机的硬件或软件配置发生了显着变化，则结果将不完整。如果计算机从未进行过在线扫描，则 IUpdateSearcher::Search 不会返回错误 - 它只会立即报告没有适用的更新。

因此，如果您想尝试通过执行脱机扫描来加快速度，检查 IAutomaticResults::LastSearchSuccessDate 是一个很好的编码习惯，它会告诉您自动更新上次执行扫描的时间。由于自动更新扫描是在线的，因此您知道当时发生了在线扫描。如果日期已经过去几天了，您应该进行在线扫描。

长期问题:

此代码假设存在更新 KB123456 并且与计算机相关。但这本质上是一个有时间限制的假设，并且现在的时间限制通常很短。如果 KB123456 中的补丁被汇总到更新的累积更新 KB234567 中，那么在某个时候 KB123456 可能会过期Windows更新。此时，即使修补后的代码实际上位于 PC 上，您的搜索也将始终返回“未安装”。

结论

与其尝试检查“KB X 是否已安装？”，更好的方法是测试“是否安装了我需要的修复/功能？”

• 如果可能的话，直接检查修复/功能。例如，如果您需要特定的新 Windows API，那么您可以使用 API Sets(如果操作系统支持)，或者仅使用 LoadLibrary 和 GetProcAddress 来查看您要查找的 DLL 是否包含您需要的函数。

• 如果无法直接测试修复/功能，请测试 Windows 本身的状态以查看是否是您所需要的。在 Windows 10 中，您通常只需要检查内部版本号。在旧版本的操作系统上，您可以查看 KB 的补丁说明，找出它更新的 DLL 以及将它们更新到的版本号，而不是硬编码 KB 编号，然后在运行时使用这些 DLL 名称和版本检查。

• 根据您正在测试的内容以及进行测试的上下文(脚本等)，DISM 命令也可能会有所帮助 - 如果您需要特定的 Windows 软件包目前，您可以使用 DISM/ONLINE/GET-PACKAGES 并查看您的包是否显示在输出中。