What causes "Failed to open registry key {subkey}: {err}" in rustdesk/rustdesk?

Run the process elevated (as administrator) so HKLM keys are readable

Failed to open registry key {subkey}: {err}

Error message

Failed to open registry key {subkey}: {err}

What it means

`get_reg_string_of` opens an HKLM subkey (path stripped of the HKLM prefix) to read a string value. A missing key is treated as `Ok(None)`, but any other open failure (e.g. access denied, invalid key name) bails with this error including the subkey and the io error.

Source

Thrown at src/platform/windows.rs:3660

fn build_msi_uninstall_command(product_code: &str) -> String {
    format!(
        "set \"RUSTDESK_MSI_EXIT_CODE=\"\n\
MsiExec.exe /X {product_code} /norestart REBOOT=ReallySuppress\n\
set \"RUSTDESK_MSI_EXIT_CODE=%ERRORLEVEL%\"\n\
if \"%RUSTDESK_MSI_EXIT_CODE%\"==\"{MSI_EXIT_SUCCESS_REBOOT_REQUIRED}\" echo MSI uninstall succeeded with a reboot recommendation; continuing without reboot.\n\
if \"%RUSTDESK_MSI_EXIT_CODE%\"==\"{MSI_EXIT_SUCCESS_REBOOT_INITIATED}\" echo MSI uninstall succeeded with a reboot request; continuing without forcing reboot.\n\
if not \"%RUSTDESK_MSI_EXIT_CODE%\"==\"0\" if not \"%RUSTDESK_MSI_EXIT_CODE%\"==\"{MSI_EXIT_SUCCESS_REBOOT_REQUIRED}\" if not \"%RUSTDESK_MSI_EXIT_CODE%\"==\"{MSI_EXIT_SUCCESS_REBOOT_INITIATED}\" exit /b %RUSTDESK_MSI_EXIT_CODE%\n\
ver > nul"
    )
}

fn get_reg_string_of(subkey: &str, name: &str) -> ResultType<Option<String>> {
    let hklm = RegKey::predef(HKEY_LOCAL_MACHINE);
    let path = subkey.strip_prefix(HKLM_PREFIX).unwrap_or(subkey);
    let key = match hklm.open_subkey(path) {
        Ok(key) => key,
        Err(err) if err.kind() == std::io::ErrorKind::NotFound => return Ok(None),
        Err(err) => bail!("Failed to open registry key {subkey}: {err}"),
    };
    match key.get_value::<String, _>(name) {
        Ok(value) => Ok(Some(value)),
        Err(err) if err.kind() == std::io::ErrorKind::NotFound => Ok(None),
        Err(err) => bail!("Failed to read {name} from registry key {subkey}: {err}"),
    }
}

fn get_windows_installer_state(subkey: &str) -> ResultType<Option<bool>> {
    let hklm = RegKey::predef(HKEY_LOCAL_MACHINE);
    let path = subkey.strip_prefix(HKLM_PREFIX).unwrap_or(subkey);
    let key = match hklm.open_subkey(path) {
        Ok(key) => key,
        Err(err) if err.kind() == std::io::ErrorKind::NotFound => return Ok(None),
        Err(err) => bail!("Failed to open registry key {subkey}: {err}"),
    };
    match key.get_value::<u32, _>(REG_NAME_WINDOWS_INSTALLER) {
        Ok(value) => Ok(Some(value == MSI_WINDOWS_INSTALLER_VALUE)),

View on GitHub (pinned to 91c9fccbb0)

Solutions

Run the process elevated (as administrator) so HKLM keys are readable
Verify the subkey string is correct and exists (regedit / `reg query`); note NotFound is already handled as None so this error means something other than absence
Check bitness: open the 64-bit view explicitly (KEY_WOW64_64KEY) if the key lives in the native view
Inspect the embedded io error for the exact Win32 code (5 = access denied, 87 = invalid parameter)

Example fix

// caller handling
match get_reg_string_of(subkey, "DisplayVersion") {
    Ok(v) => { /* None means key/value missing */ }
    Err(e) if e.to_string().contains("Failed to open registry key") => {
        // not elevated or key unreadable — retry elevated or degrade gracefully
    }
    Err(e) => return Err(e),
}

Defensive patterns

Strategy: try-catch

Validate before calling

// probe readability beforehand (elevated check)
let hklm = RegKey::predef(HKEY_LOCAL_MACHINE);
let readable = hklm.open_subkey(path).map(|_| ()).is_ok();
if !readable { /* request elevation or skip */ }

Try / catch

match get_reg_string_of(subkey, name) {
    Ok(Some(v)) => v,
    Ok(None) => default_value,
    Err(e) => { log::warn!("{e}"); default_value }
}

Prevention

Run registry-reading install checks elevated
Treat Ok(None) as 'absent' and this error as 'access/validity' — handle them differently
Verify subkey constants against regedit output
Consider WOW64 view (KEY_WOW64_64KEY) when reading native keys

When it happens

Trigger: Calling registry-reading helpers with a subkey that exists in name but cannot be opened — typically `ERROR_ACCESS_DENIED` from reading protected uninstall keys without elevation, or a malformed subkey path with invalid characters.

Common situations: Running the client without administrator rights while reading `HKLM\...\Uninstall\...` keys restricted by ACLs; 32/64-bit registry view mismatch (key exists only in WOW64 view); typo in subkey constant.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

AI-assisted analysis of rustdesk/rustdesk@91c9fccbb0 (2026-09-10). Data as JSON: /api/errors/c2e794b736c23898. Report an issue: GitHub.