Supported API-set version resolution verification for synch-l1-2-0 on Windows 26300.9711 x64-

Question

Hello Microsoft Windows API Team,

We are assessing native dependencies for a proposed Windows packaged desktop application using Microsoft.VCLibs.140.00.UWPDesktop version 14.0.33321.0 (x64).

We need technical clarification about two unresolved static imports. We have not observed or claimed a runtime failure.

Environment:

• Windows build: 26300.9711, x64

Framework: Microsoft.VCLibs.140.00.UWPDesktop 14.0.33321.0

External import occurrences examined: 335

Statically verified: 333

Proven mismatches: 0

Unresolved: 2

Technical findings:

KERNEL32.dll forwards these two functions to api-ms-win-core-synch-l1-2-0:

InitOnceExecuteOnce

SleepConditionVariableSRW

However, the captured API-set schema contains an entry for api-ms-win-core-synch-l1-2-1, with kernelbase.dll as its default host.

The schema entry also contains a hashed-prefix relationship with api-ms-win-core-synch-l1-2, but we have not established an authoritative Windows loader rule explaining how that relationship applies to the requested l1-2-0 contract.

KernelBase exports both function names directly.

We have not assumed that the l1-2-0 and l1-2-1 contracts are interchangeable.

Our questions:

How does the Windows loader resolve api-ms-win-core-synch-l1-2-0 when the captured schema contains api-ms-win-core-synch-l1-2-1? Does the shared hashed prefix participate in resolution?

Is GetApiSetModuleBaseName an appropriate supported diagnostic for verifying this exact contract on Windows build 26300.9711? What prerequisites and limitations apply?

Is there official Microsoft documentation or a supported verification procedure that establishes the mapping for these two functions on this Windows build?

We have reviewed:

https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets

https://learn.microsoft.com/en-us/windows/win32/apiindex/api-set-loader-operation

https://learn.microsoft.com/en-us/windows/win32/api/apiquery2/nf-apiquery2-getapisetmodulebasename

Our objective is to resolve a static dependency evidence gap. We are not asserting runtime compatibility or incompatibility.

Thank you for your guidance.

609 Blaze BusinessHello Microsoft Windows API Team,

We are assessing native dependencies for a proposed Windows packaged desktop application using Microsoft.VCLibs.140.00.UWPDesktop version 14.0.33321.0 (x64).

We need technical clarification about two unresolved static imports. We have not observed or claimed a runtime failure.

Environment:

Windows build: 26300.9711, x64

Framework: Microsoft.VCLibs.140.00.UWPDesktop 14.0.33321.0

External import occurrences examined: 335

Statically verified: 333

Proven mismatches: 0

Unresolved: 2

Technical findings:

KERNEL32.dll forwards these two functions to api-ms-win-core-synch-l1-2-0:

InitOnceExecuteOnce

SleepConditionVariableSRW

However, the captured API-set schema contains an entry for api-ms-win-core-synch-l1-2-1, with kernelbase.dll as its default host.

The schema entry also contains a hashed-prefix relationship with api-ms-win-core-synch-l1-2, but we have not established an authoritative Windows loader rule explaining how that relationship applies to the requested l1-2-0 contract.

KernelBase exports both function names directly.

We have not assumed that the l1-2-0 and l1-2-1 contracts are interchangeable.

Our questions:

How does the Windows loader resolve api-ms-win-core-synch-l1-2-0 when the captured schema contains api-ms-win-core-synch-l1-2-1? Does the shared hashed prefix participate in resolution?

Is GetApiSetModuleBaseName an appropriate supported diagnostic for verifying this exact contract on Windows build 26300.9711? What prerequisites and limitations apply?

Is there official Microsoft documentation or a supported verification procedure that establishes the mapping for these two functions on this Windows build?

We have reviewed:

https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets

https://learn.microsoft.com/en-us/windows/win32/apiindex/api-set-loader-operation

https://learn.microsoft.com/en-us/windows/win32/api/apiquery2/nf-apiquery2-getapisetmodulebasename

Our objective is to resolve a static dependency evidence gap. We are not asserting runtime compatibility or incompatibility.

Thank you for your guidance.

609 Blaze Business

Answer 1

Hi @Prosanta Roy ,

Thank you for the detailed write-up and questions. Here are my answers to them:

1. How is api-ms-win-core-synch-l1-2-0 resolved when the captured schema is containing api-ms-win-core-synch-l1-2-1? Does the hashed prefix participate?

The public documentation doesn't describe how the schema matches a requested contract version against the entries it contains. It also doesn't describe what role, if any, the hashed prefix plays in that matching.

What the documentation does establish:

• A name beginning with api- or ext- is routed to the API set runtime, parsed by API set naming rules, and resolved through the schema composed for the running system.
• A versioned contract name identifies a specific version of a contract and should be treated as an immutable identifier.
• The contract-to-host mapping is a property of the running OS and can vary by device.

Since the internal matching rule isn't published, the captured schema structure on its own isn't a reliable basis for this conclusion. The supported approach is to ask the running system directly how it resolves the exact contract name, as described below.

2. Is GetApiSetModuleBaseName an appropriate supported diagnostic for this contract? What prerequisites and limitations apply?

The documentation says the function resolves contract names the same way the loader does and is intended for tools that analyze dependencies between Windows binaries. The full versioned name api-ms-win-core-synch-l1-2-0 can be passed as it appears in the forwarder. The .dll suffix is optional.

The same page lists these prerequisites and limitations:

Availability: The function is carried by api-ms-win-core-apiquery-l2-1-1 and isn't present on every system. No import library provides a downlevel-capable binding, so it has to be bound dynamically:

• Call IsApiSetImplemented("api-ms-win-core-apiquery-l2-1-1").
• If it returns TRUE, call LoadLibrary and GetProcAddress.
• Check the returned HRESULT.

Scope: The result is a schema lookup only. The function doesn't search the file system, confirm the module exists, load it, or inspect its exports.

Error interpretation: GetApiSetModuleBaseName and IsApiSetImplemented apply different resolution rules. Because of that, HRESULT_FROM_WIN32(ERROR_OBJECT_NOT_FOUND) isn't equivalent to IsApiSetImplemented returning FALSE. Use FAILED to test results rather than comparing against specific codes.

Build scope: The result reflects the schema on the machine where it runs. It applies to build 26300.9711 only when run on that build.

3. Is there official documentation or a supported procedure that establishes the mapping for these two functions on this build?

The documentation doesn't publish a per-build table of contract-to-host mappings. It describes the mapping as composed for each running system, not as a fixed list.

It does define three requirements for a call to reach its implementation:

• The contract is present in the schema.
• The schema maps the contract to a loadable host binary.
• The host exports the specific function.

Your existing evidence plus one query can cover all three:

• Requirements 1 and 2: On build 26300.9711 x64, call GetApiSetModuleBaseName("api-ms-win-core-synch-l1-2-0") and record the returned host.
• Requirement 3: If the host is kernelbase.dll, your existing finding that KernelBase exports InitOnceExecuteOnce and SleepConditionVariableSRW covers it.
• Optional runtime confirmation: Call LoadLibraryExW(L"api-ms-win-core-synch-l1-2-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32), then GetProcAddress for both functions. This confirms behavior on that build only, not across builds.

I hope this helps and provide you the answers you need. Feel free to leave a comment if you have any other questions.

If this instruction is applicable to your situation, I would greatly appreciate it if you could follow the instruction here so others experiencing similar behavior can benefit from it as well.