After adding StereoTool VST plugin to filters on a source, going into OBS Settings presents 'Could not find locale.ini path' then crashes

[biosmatrix123]

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

27.2.4

OBS Studio Version (Other)

No response

OBS Studio Log URL

removed

OBS Studio Crash Log URL

removed

Expected Behavior

Not to crash! And show OBS Settings

Current Behavior

OBS Crashes after pressing 'OK' to the Error dialog

Steps to Reproduce

1. Obtain the StereoTool VST Plugin (Demo version is fine) and place in appropriate directory.
2. Add a media source to use the VST plugin with
3. Add VST 2.x Plug-in and then select the StereoTool VST Plugin to the Audio/Video Filters of the added media source
4. Open the Plug-in Interface
5. Within the StereoTool interface, under 'Configuration' options, click the 'Preset' button, under Generic Presets load the top one (Mathijs Vos & Hans ....."
6. Click Save - save all settings
7. Click Load, load all settings and select the file you just saved in step 6.
8. Close StereoTool interface
9. Open OBS Settings - it will show the 'Could not find locale.ini path' error and upon pressing OK, crash.

Anything else we should know?

This only seems to happen once - until you change StereoTool settings or load a(nother) preset.

[WizardCM]

Please try without the following third party plugins, which may be conflicting and/or outdated:

11:47:04.987:   Loaded Modules:
11:47:04.987:     spectralizer.dll
11:47:04.987:     obs-websocket.dll
11:47:04.987:     obs-gstreamer.dll
11:47:04.987:     advanced-scene-switcher.dll

[biosmatrix123]

Please try without the following third party plugins, which may be conflicting and/or outdated:

11:47:04.987:   Loaded Modules:
11:47:04.987:     spectralizer.dll
11:47:04.987:     obs-websocket.dll
11:47:04.987:     obs-gstreamer.dll
11:47:04.987:     advanced-scene-switcher.dll

Nope - no different. I'm pretty sure they have absolutely nothing to do with this issue.

[WizardCM]

I cannot reproduce this on a clean 27.2.4 OBS version running on Windows 10.

Using the standalone .dll downloaded from https://www.stereotool.com/download/

[biosmatrix123]

I cannot reproduce this on a clean 27.2.4 OBS version running on Windows 10.

That's surprising! I can reproduce it each time, on 2 different systems.... I'm happy to blow my installation away totally and just try StereoTool alone with no other plugins being installed.

Can you confirm you're saving a preset within StereoTool then loading it - then going to Settings ?

[WizardCM]

Yep, clicked Save, then clicked Load. You can test without the third party plugins without blowing away your installation, just download the portable ZIP of OBS available on the website.

[biosmatrix123]

Yep, clicked Save, then clicked Load. You can test without the third party plugins without blowing away your installation, just download the portable ZIP of OBS available on the website.

Ok - So I did this and the issue occurred still.....Can you try this?....

1. Remove the filter / VST plugin from the source.
2. Add it back in
3. Open StereoTool interface
4. Goto 'Configuration' section and then click the 'Preset' button, under Generic Presets load the top one (Mathijs Vos & Hans ....."
5. Click Save - save all settings
6. Click Load, load all settings and select the file you just saved in step 5.
7. Close StereoTool etc, goto 'Settings'
8. Issue should now be reproduced (I hope!)

[WizardCM]

Aha, confirmed. I'm not 100% sure if the code is on the obs-vst side or on the OBS Studio side, but I'll mark it as confirmed and will revisit later. Please update the original issue description with the confirmed reproduction steps.

[biosmatrix123]

Great - got there in the end! Have updated the issue description.

[notr1ch]

This sounds like a DLL (probably StereoTool) is changing the current directory of the process which is bad behavior, the process is responsible for its own directory. Per MSDN:

The current directory is shared by all threads of the process: If one thread changes the current directory, it affects all threads in the process. Multithreaded applications and shared library code should avoid calling the SetCurrentDirectory function due to the risk of affecting relative path calculations being performed by other threads. Conversely, multithreaded applications and shared library code should avoid using relative paths so that they are unaffected by changes to the current directory performed by other threads.

I have for some time wanted to avoid OBS depending on the current directory, perhaps this is the motivation to do so :).

[biosmatrix123]

This sounds like a DLL (probably StereoTool) is changing the current directory of the process which is bad behavior, the process is responsible for its own directory. Per MSDN:

The current directory is shared by all threads of the process: If one thread changes the current directory, it affects all threads in the process. Multithreaded applications and shared library code should avoid calling the SetCurrentDirectory function due to the risk of affecting relative path calculations being performed by other threads. Conversely, multithreaded applications and shared library code should avoid using relative paths so that they are unaffected by changes to the current directory performed by other threads.

I have for some time wanted to avoid OBS depending on the current directory, perhaps this is the motivation to do so :).

Yep you are spot on! I used Process Explorer to check the 'Current Directory' of OBS and after loading a preset, this gets changed to the directory of where the preset file is loaded from.

At least I have a workaround now (I can put the preset file we load into the OBS bin directory and load from there).

[hansvanzutphen]

Hi, the developer of Stereo Tool here.

We don't explicitly set the working directory (I agree that that would be a bad idea), but apparently the Windows open dialog does that! There is an option OFN_NOCHANGEDIR which restores the working directory after the open dialog is closed, but... it still changes it while that window is open.

So I can add that... it will make the chance of this happening smaller, but not zero.

More info here: https://stackoverflow.com/questions/50468051/how-to-prevent-getopenfilename-from-changing-the-current-directory-while-the-dia

[biosmatrix123]

Hey Hans,

I believe if you do implement that, it should resolve the issue here - thanks for your input! :)

[hansvanzutphen]

Done. I've verified it in ProcessExplorer as well, and indeed, while the window is open the directory changes, when I close it it goes back to the original directory. For who needs it: This fix will be available in the next beta build, I expect that to be available tomorrow on our forum.

[notr1ch]

Interesting - MSDN claims OFN_NOCHANGEDIR is "ineffective" for GetOpenFileName:

https://docs.microsoft.com/en-us/windows/win32/api/commdlg/ns-commdlg-openfilenamea

[ElSaico]

...well would you look at that.

Turns out THIS is what's behind the crashes with my Cabbage VST plugin; I was finding it weird that:

• OBS only crashes on reopening
• the actual thread which crashes is the obs-browser one, despite the VST being the culprit (rename/move it and things start working again)
• the logs show an "invalid file" message about an unrelated file that's still there

I'll ask around in the Cabbage forums for a way to solve this, then.

Meanwhile - and it's a moonshot about an entirely unrelated plugin: did it work before 27.2? Both major virtual background plugins remain broken on Windows for non-CUDA GPUs ever since (kounoike/obs-virtualbg#58, royshil/obs-backgroundremoval#87), and the underlying cause seems to be that they attempt to load DirectML from the wrong place...

[hansvanzutphen]

I see that I never posted an update, you can find the new Stereo Tool beta build with this fix here: https://forums.stereotool.com/viewtopic.php?f=14&t=32702

[biosmatrix123]

I see that I never posted an update, you can find the new Stereo Tool beta build with this fix here: https://forums.stereotool.com/viewtopic.php?f=14&t=32702

I'm afraid the issue still happens :( Downloaded https://www.stereotool.com/download/vst_stereo_tool_64_BETA991-016.dll and can see the working directory change once the open dialog is open to load a preset - it remains set to the location the preset file is loaded from.

[hansvanzutphen]

Oh! You're right. I just searched and apparently there were 2 places in the code that could open a file dialog, and I missed the one that's used here. I just verified it again and before fixing the 2nd one it remained at the wrong value, with the fix in the other place it works as it should.

I think when I tested it before I may have closed the window using Escape instead of actually loading a preset, since that also restores the old working directory. BETA017 will be available in a few hours, new release will come after that if no new bugs are reported anymore.

[PatTheMav]

@notr1ch want to keep this open as a reminder to remove any reliance on the current working dir?

[notr1ch]

Yeah let's keep this open until we fix the dependency on the CWD.