windows-rs: Bug: Issue with using `LookupAccountSidLocalW`

Which crate is this about?

windows

Crate version

latest master

Summary

While playing around with the windows api I noticed that LookupAccountSidLocalW does not work as expected.

In a minimal example an executable is produced which crashes at runtime with exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND. This suggest to me that the function is not found where it was linked to.

Furthermore by adding crossterm = "0.25.0" to the depencies (without actually adding any code using it) I get a linker error looking for an unresolved symbol __imp_LookupAccountSidLocalW

Using the very similar function LookupAccountSidW works as expected. So it seems something is wrong with the linking of LookupAccountSidLocalW.

Toolchain version/configuration

Default host: x86_64-pc-windows-msvc

active toolchain

stable-x86_64-pc-windows-msvc (default) rustc 1.65.0 (897e37553 2022-11-02)

Reproducible example

use windows::Win32::{Foundation::PSID, Security};

fn main() {
    let sid = PSID::default();
    let mut name_size: u32 = 256;
    let mut domain_size: u32 = 256;

    let mut name: Vec<u16> = vec![0; name_size as usize];
    let mut domain: Vec<u16> = vec![0; domain_size as usize];

    let mut peuse = Default::default();

    unsafe {
        Security::LookupAccountSidLocalW(
            sid,
            windows::core::PWSTR(name.as_mut_ptr()),
            &mut name_size,
            windows::core::PWSTR(domain.as_mut_ptr()),
            &mut domain_size,
            &mut peuse,
        )
    };
}

Crate manifest

[dependencies]
windows = { git = "https://github.com/microsoft/windows-rs", features = ["Win32_Security_Authorization", "Win32_Foundation", "Win32_System_Memory"] }

Expected behavior

LookupAccountSidLocalW should work similar to LookupAccountSidW

Actual behavior

LookupAccountSidLocalW crashes at runtime or produces a linker error.

Additional comments

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (3 by maintainers)

Most upvoted comments

@stevewhims We concluded sechost.dll was not correct either; it should really just be cut from the docs. (Or minimally restored to the macro variant as Raymond suggested. It’ll at least be correct for older SDKs.)

[…] @stevewhims for the doc bug.

For the doc bug, I’ve changed the dll to sechost.dll, and left the lib blank. That’s for the A and W variants of the APIs. If that’s not right, lemme know. 😃

Thanks! -Steve

Wow, thanks everyone for figuring this out!

I don’t have a valid workaround for developers that want local-only resolution behavior at this time.

Thats unfortunate but at least I know now why things were not working as expected.