Bug: [Windows] FTS extension 0.18.1 requires OpenSSL DLLs that are not distributed

[GlitterKill]

Ladybug version

0.18.1

What operating system are you using?

Windows 11 x64

What happened?

Problem

On a clean Windows installation, the FTS extension cannot load because it depends on two OpenSSL 3 libraries that are not distributed with either @ladybugdb/core or the downloaded extension:

• libssl-3-x64.dll
• libcrypto-3-x64.dll

INSTALL fts successfully downloads libfts.lbug_extension, but LOAD EXTENSION fts fails with Windows error 126: “The specified module could not be found.”

Inspection of the extension's import table confirms that it imports both OpenSSL DLLs.

Diagnostic workaround

Prepending an existing OpenSSL 3 installation to PATH makes the same extension load successfully. For example, Git for Windows happens to contain compatible DLLs on some machines:

$env:Path = "C:\Program Files\Git\mingw64\bin;$env:Path"
node .\repro.mjs

This confirms the missing dependency, but relying on another application's private DLLs is not a safe deployment solution.

Expected behavior

The Windows FTS extension should work on a clean supported Windows installation.

Possible fixes include:

1. Distribute the required OpenSSL DLLs beside libfts.lbug_extension.
2. Statically link OpenSSL into the Windows extension.
3. If users must install OpenSSL themselves, document the requirement and report the exact missing DLL rather than the generic Windows error 126.

A clean-Windows CI test should install and load FTS without inheriting OpenSSL from Git, Conda, or another tool's PATH.

Impact

Applications using LadybugDB cannot reliably enable FTS on Windows. Behavior currently depends on unrelated software having placed compatible OpenSSL DLLs on the machine's PATH.

Related issues

• LadybugDB Windows FTS loading crash: LOAD EXTENSION fts segfaults on Windows 11 (Node 22, @ladybugdb/core 0.15.4) #431
• Downstream diagnosis confirming the missing DLLs: FTS exists, but it still reports that LadybugDB does not exist. abhigyanpatwari/GitNexus#2374
• Similar OpenSSL packaging problem on macOS: Bug: darwin-arm64 prebuilt lbugjs.node hardcodes Homebrew OpenSSL paths — dlopen fails on Macs without Homebrew (regression from 0.15.3) #681

Are there known steps to reproduce?

// repro.mjs
import lbug from "@ladybugdb/core";

const db = new lbug.Database("./fts-repro.lbug");
const conn = new lbug.Connection(db);

try {
  await conn.query("INSTALL fts");
  await conn.query("LOAD EXTENSION fts");
  console.log("FTS loaded successfully");
} catch (error) {
  console.error(error);
  process.exitCode = 1;
} finally {
  await conn.close();
  await db.close();
}

npm install @ladybugdb/core@0.18.1

where.exe libssl-3-x64.dll
where.exe libcrypto-3-x64.dll

node .\repro.mjs

On a clean machine, both where.exe checks report that the files cannot be found and the extension fails to load.

[freya0926]

Hi @adsharma — I'd like to work on this if it's not already spoken for.

Given the position you stated on #681 (no bundling OpenSSL into ladybug, prefer resolving against a properly-maintained OpenSSL install), I'd propose a Windows analog to the approach that landed in #682 for macOS rather than option 1 from the issue body:

• At FTS-extension load time, search well-known Windows OpenSSL install locations (the official OpenSSL Win64 installer's default path, common vcpkg/Conan install layouts, and the registry key the official installer registers) via AddDllDirectory/SetDllDirectory before LoadLibraryEx, instead of silently inheriting whatever happens to already be on PATH from an unrelated tool (as the issue itself notes, that's not a safe deployment story).
• Independent of the search-path work: catch the Windows error 126 case specifically and report which exact dependent DLL failed to resolve (e.g. by probing libssl-3-x64.dll / libcrypto-3-x64.dll individually before the real load), so users get an actionable message instead of the generic "module could not be found" — this alone is a small, low-risk improvement that could land even ahead of the path-search work.

Would that direction work for you, or is there a preferred detection strategy (e.g. registry-only, or matching #682's approach more literally)? Happy to start once you confirm.

[adsharma]

I don't want a lot of complexity added to CI to try and handle every type of windows installation.

How about a single env variable similar to LD_LIBRARY_PATH on Linux?

[freya0926]

Thanks — env var it is, I'll drop the well-known-location scanning.

Planning to call it LADYBUG_EXTENSION_LIB_PATH, matching the LADYBUG_* prefix already used for the documented proxy variables (LADYBUG_HTTP_PROXY and friends), rather than the LBUG_* prefix that seems reserved for internal debug knobs. Semicolon-separated absolute directories, registered via AddDllDirectory before the extension loads.

One thing worth flagging: the LOAD_LIBRARY_SEARCH_* flags needed for AddDllDirectory to take effect drop PATH from the loader's search order. Since prepending OpenSSL to PATH is the workaround people are using today, I'm only opting into those flags when the variable is set, so existing setups keep working.

Scoping this to Windows — on Linux/macOS the platform loader paths already cover it. Will also make error 126 name the missing DLLs instead of just the extension. Sound right?

[freya0926]

Status update, including what I could and could not verify locally.

What I built: LADYBUG_EXTENSION_LIB_PATH read in the Windows dlopen shim in src/extension/extension.cpp, registering each directory via AddDllDirectory and loading with LoadLibraryExW + LOAD_LIBRARY_SEARCH_*. The flags are only applied when the variable is set, since they drop PATH from the search order and prepending OpenSSL to PATH is the workaround people use today. Plus a hint on error 126 naming the likely missing DLLs.

Verified: compiles clean on MSVC 14.44 (VS 2022 Build Tools, Windows SDK 10.0.26100), full static Release build links. That was my main worry — AddDllDirectory needs _WIN32_WINNT >= 0x0602 and I wanted to confirm the project settings allow it.

Not verified: the runtime behaviour. My locally built lbug_shell.exe crashes with 0xC0000409 (BEX64, faulting module ucrtbase.dll) as soon as it opens a database — :memory: or file-backed, with or without -i. --version works. I rebuilt with extension.cpp reverted to its pre-change state and got the identical crash, so it is not from my change; it looks environmental (Windows 10 19043 here). Happy to file that separately if it is not already known.

A question that affects whether this approach is right at all.

dumpbin /dependents on my build shows lbug_shell.exe importing libssl-3-x64.dll and libcrypto-3-x64.dll directly — the core links OpenSSL 3, not just the extension. If the released Windows core does the same, then by the time LOAD EXTENSION fts runs, libssl-3-x64.dll is already loaded in the process, the loader resolves the extension's import by module name without searching, and the env var would never come into play — meaning this change would not actually fix #685.

For the reported failure to happen at all, the released core seemingly cannot depend on those DLLs at runtime, or INSTALL fts would not have worked either. So the release must be built differently from what I get locally, but I could not find Windows OpenSSL configuration in CI — ci-workflow.yml just runs make release on the Windows runner and relies on whatever OpenSSL is on it.

@adsharma could you confirm how the released Windows core links OpenSSL? If it is static, this approach holds. If it is dynamic, the problem is broader than extension loading and the fix probably belongs in packaging instead.

One design note: each directory in the variable becomes somewhere the process loads code from, so it is worth documenting that they must not be writable by untrusted users. A directory created directly under C:\ inherits write access for Authenticated Users by default, which is an easy way to get this wrong — I hit exactly that setting up my own test environment.

[adsharma]

We link OpenSSL dynamically.