Windows: Fluid Intelligence fails when incompatible System32 libomp takes precedence

[kpadams94]

Summary

FluidVoice Windows 0.0.5 could not load the Fluid Intelligence llama.cpp backend when an older libomp140.x86_64.dll was present in C:\Windows\System32.

Windows resolved that system DLL instead of FluidVoice's compatible bundled copy. This produced an entry-point error for __kmpc_dispatch_deinit and prevented both the CUDA and CPU llama backends from loading.

Placing FluidVoice's bundled libomp140.x86_64.dll beside fluidvoice.exe fixed the problem immediately.

Environment

• FluidVoice Windows 0.0.5 beta
• Windows 10 Pro x64, build 19045
• Intel Core i7-6700K
• NVIDIA GeForce RTX 2070, compute capability 7.5
• CUDA driver API reported by FluidVoice: 13.3
• llama runtime: llama-b9870

Steps to reproduce

1. Install FluidVoice Windows 0.0.5.
2. Complete onboarding and download the local speech/Fluid Intelligence models and runtimes.
3. Enable or invoke Fluid Intelligence.
4. Restart FluidVoice.
5. Observe the Windows entry-point error while loading:
   %LOCALAPPDATA%\FluidVoice\Runtimes\llama-cpp\llama-b9870\cuda\ggml-base.dll

Error

fluidvoice.exe - Entry Point Not Found

The procedure entry point __kmpc_dispatch_deinit could not be located
in the dynamic link library:
%LOCALAPPDATA%\FluidVoice\Runtimes\llama-cpp\llama-b9870\cuda\ggml-base.dll

Relevant FluidVoice log output:

Fluid Intelligence backend candidate failed: accelerator=cuda,
error=failed to load ...\llama-b9870\cuda\llama.dll

Fluid Intelligence backend candidate failed: accelerator=cpu,
error=failed to load ...\llama-b9870\cpu\llama.dll

Fluid Intelligence startup warmup failed:
No llama.cpp backend could load Fluid-1.

Diagnosis

Two different OpenMP runtimes were present:

System copy selected by Windows

C:\Windows\System32\libomp140.x86_64.dll
Size: 1,664,912 bytes
SHA-256: E8A22979342BA8D5F34E3500AE9A5DB1C1833A77446AA969C296345570178E37
__kmpc_dispatch_deinit: missing

FluidVoice bundled copy

%LOCALAPPDATA%\FluidVoice\Runtimes\llama-cpp\llama-b9870\cpu\libomp140.x86_64.dll
Size: 661,856 bytes
SHA-256: 4A20C1E5C115C29771A12324513EB109BADAC72180F79481527AD79D996FFB33
__kmpc_dispatch_deinit: present

The bundled CPU and CUDA copies were identical. Loading llama.dll in a fresh process with the runtime directory selected succeeded, which further indicated a DLL search-order conflict inside the FluidVoice process rather than corrupt runtime files or GPU incompatibility.

Workaround

Copying FluidVoice's bundled OpenMP DLL to the application directory:

%LOCALAPPDATA%\FluidVoice\libomp140.x86_64.dll

and restarting FluidVoice resolved the issue without modifying System32.

After the workaround, FluidVoice reported:

Loaded Fluid Intelligence llama.cpp backend:
accelerator=cuda, gpu_layers=-1, backend_argmax=true

A subsequent enhancement completed successfully on CUDA in 475 ms.

Expected behavior

FluidVoice should load the OpenMP runtime bundled with its selected llama runtime, regardless of another libomp140.x86_64.dll in System32 or PATH.

Possible direction

Ensure the runtime directory is used for dependent-DLL resolution before loading llama.dll—for example, with an isolated DLL search path—or ship the compatible OpenMP dependency beside fluidvoice.exe.

[kpadams94]

Follow-up: I started preparing a deterministic Windows loader regression test and an upstream fix, but the public windows-main branch is only a release stub and explicitly says the Windows source is not published there.

Is the official Rust/Tauri Windows 0.0.5 source available in another repository or branch, or is there a way for contributors to obtain access?

If the Windows source must remain private, would a standalone deterministic reproducer plus an implementation/test specification for the DLL-loading path still be useful? I can prepare an isolated harness covering the conflicting-libomp140.x86_64.dll scenario without modifying System32 or relying on the app-local workaround.