WASDK APIs to detect installed KBs

[sylveon]

Proposal: WASDK APIs to detect installed KBs

Summary

WASDK should offer a reliable way to detect if a specific KB is installed, that would work in the situation I mention above (a clean install with superseding updates).

Rationale

I've recently hit an interesting pickle in my program: I rely on a specific KB for builds in the 19041 series for a specific feature to work, because it includes a fix to a bug that was affecting my program. However there is no way to "feature detect" the fix because the fix amounted to adding a null check somewhere.

This leaves me needing to detect the KB is present on those builds). Unfortunately at the moment there are no good ways to detect KBs. I first thought of using WMIC or the WU API to detect KBs, but both run in a severe issue: if a computer is clean installed, and a KB that supersedes the one I'm looking for exists, the OS will install the KB and never list the KB i'm looking for in the list of installed updates.

I was recommended by @jonwis to use VerifyVersionInfo and the version helper macros to check for this, but unfortunately VerifyVersionInfo cannot check for a specific revision ID, it only goes as far as checking for the build number. Additionally, the version helper macros do not support checking for a specific build of Windows 10, so I have to manually call VerifyVersionInfo for that (related: http://task.ms/40370770).

Which means I have to rely to something that is generally not recommended: raw version checking. Once I establish that the OS build is 19041-19044 (19045 and up always has the fix) via VerifyVersionInfo I have to check if the revision ID of the build is equal or higher to the revision ID of the KB I'm relying on. So I have to call RtlGetVersion (which is not supposed to be usable from user mode, mind you), or read the file version from ntoskrnl.exe to get the revision ID, then I can compare.

Scope

Capability	Priority
Allows developers to detect if a KB is installed on the machine, even if superseded by another KB	Must
Allows developers to check which build of the OS is installed on (WinRT VerifyVersionInfo equivalent)	Should
Allows developers to get the OS revision ID	Won't

Important Notes

WinRT API

A simple API I threw together real quick, names aren't really good:

namespace Microsoft.System.Updates
{
    static class UpdateManager
    {
        // equivalent to the future IsWindows10BuildOrGreater function from the PSDK
        // e.g. to check for Windows 11, one would call IsAtLeastBuild(22000)
        // would be nice to provide constants for those build IDs somewhere
        public static bool IsAtLeastBuild(uint buildId);
        // to check if KB5007253 is installed, one would call `IsCumulativeUpdateInstalled(5007253)`
        public static bool IsCumulativeUpdateInstalled(uint updateId);
    }
}

Open Questions

One thing I left open for interpretation, is whether KBs from previous OS versions should be reported as installed on newer OS builds, if the corresponding fixes are built-in to the OS build. This is pretty complex, and I'd be okay with not implementing that, instead having developers check the OS build before checking for KBs.

[riverar]

(Apologies for the answer, the Windows App SDK team still hasn't fixed the Ideas category.)

Interesting. Can you share more information on what feature you're using/trying to detect? Maybe others can help identify a better path?

Which means I have to rely to something that is generally not recommended: raw version checking. Once I establish that the OS build is 19041-19044 (19045 and up always has the fix) via VerifyVersionInfo I have to check if the revision ID of the build is equal or higher to the revision ID of the KB I'm relying on.

Unfortunately, this may inadvertently exclude users on, say, 19044.xx that have been serviced and are supported by your app. I'm also curious how well this will hold up with Microsoft's increased use of enablement packages—updates that artificially tweak the OS version number to differentiate between deployments.

[sylveon]

Interesting. Can you share more information on what feature you're using/trying to detect? Maybe others can help identify a better path?

I'm trying to detect the fix to microsoft/microsoft-ui-xaml#3529. I was told by @jonwil there is no direct way to detect it, because it's too trivial of a fix.

Unfortunately, this may inadvertently exclude users on, say, 19044.xx that have been serviced and are supported by your app

How so? If I detect 19044, then I check if the KB is there by looking at the version. If I detect 19045, I assume it's fixed (because AFAIK 19045 will always have that KB installed).

[DrusTheAxe]

Interesting ask. Could you write up an Issue summarizing the ask? Please use this template

# Proposal: <name>

## Summary
<summary>

## Rationale
<rationale>

## Scope
| Capability | Priority |
| :---------- | :------- |
| APIs equivalent to Windows.Storage.ApplicationData (minus deprecated APIs)| Must-or-Should-or-Can (i.e. required, optional nice-to-have, aka P1/2/3) |

## Important Notes

<notes>

## WinRT API

<API suggestions, if any>

## Open Questions

Q: <question/issue>

like here #2639

[sylveon]

Sure, edited the original post. I was told to not use ProductBoard but the template was gone and I couldn't find it.

[driver1998]

I guess it might be easier to detect the UBR (Update Build Revision) value instead of detecting KBs? Of course that would also require a documented method (instead of reading from the registry).

[sylveon]

That's what I'm doing currently, but I was explicitly told it's not recommended by @jonwis