DLL issue with WaitOnAddress/WakeByAddressSingle/WakeByAddressAll

[m-ou-se]

Which crate is this about?

windows-sys

Crate version

0.36.1

Summary

Using the WaitOnAddress/WakeByAddressSingle/WakeByAddressAll APIs works fine on Windows 10 pro, but results in 0xc0000142 (STATUS_DLL_INIT_FAILED) on GitHub's CI, which runs Windows Server 2022 (10.0.20348). The binary also fails to run in Wine, complaining that it can't find vertdll.dll.

dumpbin /imports shows that these three functions get imported from vertdll.dll, but I don't know whether that's correct, or whether that's also the problem I see on Windows Server.

Toolchain version/configuration

Default config of GitHub's windows-latest:

 Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\runneradmin\.rustup

installed targets for active toolchain
--------------------------------------

i686-pc-windows-msvc
x86_64-pc-windows-msvc

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.63.0 (4b91a6ea7 2022-08-08)

Reproducible example

use windows_sys::Win32::System::Threading::WakeByAddressSingle;

fn main() {
    unsafe { WakeByAddressSingle(std::ptr::null()) };
}

Crate manifest

[package]
name = "testcase"
version = "0.1.0"
edition = "2021"

[dependencies]
windows-sys = { version = "0.36", features = ["Win32_System_Threading", "Win32_Foundation"] }

Expected behavior

Runs fine.

Actual behavior

error: process didn't exit successfully: target\debug\repro.exe (exit code: 0xc0000142, STATUS_DLL_INIT_FAILED)

Additional comments

No response

[kennykerr]

At least on my Windows 11 machine, the function does indeed get exported from vertdll.dll:

dumpbin /exports %windir%\system32\vertdll.dll | findstr /i WaitOnAddress
        161   A0 000049E0 WaitOnAddress

Wine's not that surprising as the API is new to Windows 8, but I'd expect Windows Server 2022 to have it. Adding @riverar in case he happens to know offhand.

The latest version of the win32metadata also reports that this function is exported from vertdll.dll.

I can try to confirm the same for GitHub's CI machines.

[kennykerr]

I will add that the docs indicate otherwise:

https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress

And our internal API definition seems to confirm the docs are correct:

<Export Name="WaitOnAddress">
    <Header Name="synchapi.h"/>
    <Lib Name="synchronization.lib"/>
    <Module Name="api-ms-win-core-synch-l1-2-0.dll"/>
</Export>

Now usually these api-ms-win-...dll entries are just forwarding DLLs that really just forward to the underlying API (thanks to the loader) so it shouldn't matter but it's possible something in these forwarding DLLs was fixed in more recent builds.

[m-ou-se]

Wine's not that surprising as the API is new to Windows 8

FWIW, using the winapi crate results in a binary that wants api-ms-win-core-synch-l1-2-0.dll instead of vertdll.dll, and that binary does run fine in Wine.

[kennykerr]

Added a test to validate the CI build machine: #2028

I'll double check internally on the history of the function and figure out what's going on.

[ChrisDenton]

Looking through the 10.0.22621 sdk (Windows 11), it seems it is exported from vertdll.lib which has the vertdll.dll import. But there are also import libraries (such as WindowsApp.lib) that use the api-ms-win-core-synch-l1-2-0.dll name. This is also the name given in the documentation.

In any case, should this not be an issues for the win32metadata project? I'd guess it's picking up the name from the first import library it finds.

[m-ou-se]

Here's a branch with my minimal reproduction: https://github.com/m-ou-se/atomic-wait/tree/testcase, and here how it fails in GitHub Actions (just running cargo run on the default windows-latest): https://github.com/m-ou-se/atomic-wait/actions/runs/3070594623/jobs/4960474007

[riverar]

vertdll.dll exports this API on both Windows Server 2022 21H2 and Windows 11. Guessing the CI runners use nanoserver images and this API is implemented elsewhere, am checking.

[riverar]

vertdll.dll indeed doesn't exist on nanoserver; we'll get this fixed up on the win32metadata side!

[kennykerr]

@ChrisDenton contributed a fix to the metadata (microsoft/win32metadata#1257) and I've requested another release of the metadata at which point I can regenerate the windows and windows-sys crates.

Thanks for reporting this issue!

[kennykerr]

The fix is now in the windows-rs repo. You should be able to test it directly. Happy to release an update to the windows-sys crate if needed.

[m-ou-se]

Thank you!

A new release of windows-sys would be great. :)

[kennykerr]

windows-sys 0.42.0 has now been published!