View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0010229ardourbugspublic2026-03-03 11:372026-03-04 16:54
ReporterX_rrrr_X Assigned Tox42  
PrioritynormalSeveritymajorReproducibilitysometimes
Status resolvedResolutionfixed 
PlatformMicrosoftOSWindowsOS Version11
Product Version9.2 
Summary0010229: [Windows] Fix VST3 loading failure for Unicode paths by migrating to LoadLibraryW
DescriptionThe current implementation in libs/ardour/vst3_module.cc uses LoadLibraryA combined with Glib::locale_from_utf8 to load VST3 binary modules on Windows. While Ardour successfully identifies VST3 bundles in Unicode paths, the subsequent attempt to load the library module fails.

On Windows systems where the ANSI Code Page does not match UTF-8 characters in the plugin path (e.g., Chinese, Japanese), Glib::locale_from_utf8 produces an invalid string, causing LoadLibraryA to return ERROR_MOD_NOT_FOUND (126).

Observed Symptoms:
1. VST3 plugins in Unicode paths fail to initialize.
2. Official Nightly Debug Build console shows: "warning: Invalid parameter passed to C runtime function".

I am attaching a patch that migrates the logic to LoadLibraryW and g_utf8_to_utf16 for robust Unicode support.
Steps To Reproduce1. Place a VST3 plugin in a path with Unicode characters (e.g., D:/Plugins/Chinese_Name/OTT.vst3).
2. Run Ardour and perform a VST3 plugin scan.
3. Observe that the plugin fails to load, accompanied by CRT parameter warnings in the debug console.
Additional InformationThe patch ensures that the full Unicode path is passed correctly to the Windows API. I will upload the .patch file as an attachment to avoid character escaping issues in this text field.
TagsInternationalization, Unicode, VST3, Windows

Activities

X_rrrr_X

2026-03-03 11:37

reporter  

vst3_unicode_fix.patch (603 bytes)    
diff --git a/libs/ardour/vst3_module.cc b/libs/ardour/vst3_module.cc
index 1285b3275a..e10725cc88 100644
--- a/libs/ardour/vst3_module.cc
+++ b/libs/ardour/vst3_module.cc
@@ -133,8 +133,13 @@ public:
 #ifndef NDEBUG
 		_path = path;
 #endif
-		if ((_handle = LoadLibraryA (Glib::locale_from_utf8 (path).c_str ())) == 0) {
-			throw failed_constructor ();
+    gunichar2 *wpath = g_utf8_to_utf16(path.c_str(), -1, 0, 0, 0);
+    if (wpath) {
+      _handle = LoadLibraryW((LPCWSTR)wpath);
+      g_free(wpath);
+    }
+    if (_handle == 0) {
+      throw failed_constructor();
 		}
 
 		if (!init ()) {
vst3_unicode_fix.patch (603 bytes)   

X_rrrr_X

2026-03-03 11:39

reporter   ~0030040

Additional context: In the official Nightly Debug builds, the console shows persistent 'warning: Invalid parameter passed to C runtime function' during the scan. This confirms the CRT validation failure when LoadLibraryA encounters UTF-8 characters it cannot map to the local ANSI code page.

x42

2026-03-03 14:35

administrator   ~0030042

Thanks for the heads up.
I guess other places that use `Glib::locale_from_utf8` also need to be updated (and here specifically _handle needs to be initialized to NULL)

Could you try if using Glib::filename_from_utf8 () works here with LoadLibraryA ?

X_rrrr_X

2026-03-03 15:57

reporter   ~0030043

Thanks for the feedback!
I completely agree regarding the initialization of _handle. I will make sure to address that.

About Glib::filename_from_utf8(): My primary concern is that even with a better conversion,
LoadLibraryA is still architecturally limited by the system's legacy ANSI code page.
If a user’s path contains characters (like CJK) that don't exist in the current system's code page (e.g., CP1252),
LoadLibraryA will fail regardless of how the string is prepared by Glib.

The main advantage of LoadLibraryW is that it provides a direct,
lossless path to the Windows kernel's Unicode support,
making Ardour's VST3 loading completely independent of the user's "System Locale" settings.
This is currently the standard practice for robust Windows development.

I’m curious about the official build and target environment for Ardour.
Depending on how the binaries are built and which Windows versions they target,
it might help clarify whether filename_from_utf8 would be a sufficient fix or if the transition to the Wide API (W) is necessary for full compatibility.

x42

2026-03-03 23:09

administrator   ~0030046

> I’m curious about the official build and target environment for Ardour.

Ardour binaries are cross compiled on GNU/Linux using mingw. Windows 7 and later.
We can switch to LoadLibraryW, yet if we do that we should also replace all other places that use Glib::locale_from_utf8 for filenames (and then add some synatic sugar wrapper for g_utf8_to_utf16)

X_rrrr_X

2026-03-04 14:30

reporter   ~0030047

Thanks for the info. Cross-compiling with MinGW explains why this hasn't been caught earlier.

I've just confirmed with a standalone test on a standard Windows setup:
even with proper UTF-8 strings, LoadLibraryA consistently fails with Error 126 (ERROR_MOD_NOT_FOUND) when the path contains Unicode characters (e.g., CJK). Meanwhile, LoadLibraryW handles the same paths perfectly.
This confirms that the ANSI API's dependency on the system code page is the hard bottleneck here.

I've updated my local patch to ensure _handle is initialized to NULL (via initializer list).
Switching to the Wide API project-wide is definitely the right move to ensure robust path handling.

Once you have the g_utf8_to_utf16 wrapper ready,
I'm happy to test the final implementation to verify it resolves the VST3 issue across different locales.

x42

2026-03-04 16:54

administrator   ~0030048

Applied the patch with some small modification in 9.2-110-g3bd55406e8
Thank you!

Issue History

Date Modified Username Field Change
2026-03-03 11:37 X_rrrr_X New Issue
2026-03-03 11:37 X_rrrr_X Tag Attached: Internationalization
2026-03-03 11:37 X_rrrr_X Tag Attached: Unicode
2026-03-03 11:37 X_rrrr_X Tag Attached: VST3
2026-03-03 11:37 X_rrrr_X Tag Attached: Windows
2026-03-03 11:37 X_rrrr_X File Added: vst3_unicode_fix.patch
2026-03-03 11:39 X_rrrr_X Note Added: 0030040
2026-03-03 14:35 x42 Note Added: 0030042
2026-03-03 15:57 X_rrrr_X Note Added: 0030043
2026-03-03 23:09 x42 Note Added: 0030046
2026-03-04 14:30 X_rrrr_X Note Added: 0030047
2026-03-04 16:54 x42 Note Added: 0030048
2026-03-04 16:54 x42 Assigned To => x42
2026-03-04 16:54 x42 Status new => resolved
2026-03-04 16:54 x42 Resolution open => fixed