VSTPluginContext Dispose issue
patatattak opened this issue · comments
Hi !
I am testing vst.net.
For the moment, i just get plugins infos through VstPluginContext like that :
vstName = ctx.PluginCommandStub.GetProductString(); vstVendor = ctx.PluginCommandStub.GetVendorString(); vstVersion = ctx.PluginCommandStub.GetVendorVersion(); vstIsSynth = ctx.PluginInfo.Flags.HasFlag(Jacobi.Vst.Core.VstPluginFlags.IsSynth); ctx.Dispose();
It works well on many plugins, but i get a strange Visual Studio crash with an error code 1073741855 with a few other plugins.
My debug seems to show that the Dispose method causes the crash.
I get the problem with HGFortune Alphatron. (http://www.vst4free.com/free_vst.php?id=1033)
Hum... I just get the same crash error code, but on creating VstPluginContext with TAL-Flanger.dll.
VstPluginContext ctx = VstPluginContext.Create(dllPath, hst);
Does the problem come from my config ? I am on VS2015, with vst.netx86 (nuget pkg) on Win7 Pro.
Or does the problem come from the dlls ? (I successfully test a hundred of other plugins).
Do you have a stack trace?
The error code 1073741855 does not ring any bells...
I had the same problem earlier today when disposing a VSTPlugin - it was a segmentation fault. Currently trying to build vst.net with debugging symbols to get more insight.
In my case, the problem was hard to track down, but simple to fix: My project did use the .NET Framework 4.7. It is required to use the .NET Framework 4.0.
A simple test application with nothing more than loading the VST and disposing it right afterwards helped me reproduce the issue. 4.7 -> crash, 4.0 -> works.
Okay, I did some further testing. I built the sample Jacobi VST host. It immediately crashes when loading the Novation V-Station DLL.
Anything other than .NET Framework 4.0 and only in 64 Bit mode (32bit works with 4.7.2)
Output on the CLI:
Exception thrown: 'System.AccessViolationException' in System.Windows.Forms.dll
An unhandled exception of type 'System.AccessViolationException' occurred in System.Windows.Forms.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
That is disturbing...
Have any idea what the problem was, any stack trace?
Have any idea what the problem was, any stack trace?
No, but I'm not sure if Visual Studio has stack traces enabled by default or if I ned to enable it somewhere.
I just started with Windows Development and Visual Studio a few days back (working/developing mostly on Linux, except for music) so there's still lots to learn ;)
Look in the project settings of your managed host and select the native debugging option. Run in debug (F5) and do the thing to make it crash. It should now break on the exception and give you a call stack.
https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-debug-managed-and-native-code?view=vs-2017#configure-mixed-mode-debugging
Here's the trace I got out of it:
> V-Station x64.dll!00007ff9d2d97588() Unknown
user32.dll!UserCallWinProcCheckWow() Unknown
user32.dll!DispatchMessageWorker() Unknown
System.Windows.Forms.ni.dll!00007ff9b03634f8() Unknown
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(System.IntPtr dwComponentID, int reason = -1, int pvLoopData = 0) Unknown
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) Unknown
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) Unknown
Jacobi.Vst.Samples.Host.exe!Jacobi.Vst.Samples.Host.Program.Main() Line 16 C#
[Native to Managed Transition]
mscoreei.dll!_CorExeMain�() Unknown
mscoree.dll!_CorExeMain_Exported�() Unknown
kernel32.dll!BaseThreadInitThunk�() Unknown
ntdll.dll!RtlUserThreadStart�() Unknown
```
I'm currently trying to figure out any differences in the loaded modules - I hope that there is some difference so I can try to figure out what's going on.
Did you build Jacobi.Vst.Samples.Host with x64 or AnyCpu?
Did you build Jacobi.Vst.Samples.Host with x64 or AnyCpu?
I originally built it with x64, but I can also confirm that the same issue occurs with AnyCpu.
I also did compare the loaded modules between both .NET 4.0 and .NET 4.7 builds, the versions and locations of the loaded modules are exactly the same. I would have expected to see some difference here, since when building for .NET 4.0, the resolved DLL for System.Windows.Forms.dll is displayed in Visual Studio as C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Windows.Forms.dll and when I switch to .NET 4.7, it is displayed as C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Windows.Forms.dll. The loaded module is always C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\.
Most stuff I write in this issue is for documentation purposes while I debug along, so no need to reply to every post ;)
Surprise: I just compiled everything on a Windows 7 machine and I could not force the app with .NET 4.7.2 to crash when loading V-Station.
Investigation paths:
- The problem occurs for all Windows 10 users
- The problem occurs just on my machine
- The problem occurs only with a specific release of Windows 10
For documentation purposes, the V-Station plugin Version 2.1 crashes. I downloaded a trial version of V-Station 2.4 from Plugin Boutique, it works, as well as Version 2.6 directly from Novation (which is a bit hard to find on their site).
But since V-Station 2.1 is literally the first plugin I tested my project against, and it loads fine in all other VST hosts, I'll try to investigate this further - chances are high that this issue also occurs for other plugins.
The user32.dll!UserCallWinProcCheckWow() call suggests the plugin is not (loaded as) x64. Wow stands for Windows on Windows (like Win32 on Win64) and is a thunking layer provided by windows AFAIK. That's why I asked if you compiled with x64, which could (should?) bypass this thunking layer.
Mostly speculation on my part...
Apart from the Main entry point there is nothing in that call stack that has to do with VST.NET. So there goes something wrong with passing Windows Events to the plugin (UI?)... (again, I think)
[2c]
The
user32.dll!UserCallWinProcCheckWow()call suggests the plugin is not (loaded as) x64. Wow stands for Windows on Windows (like Win32 on Win64) and is a thunking layer provided by windows AFAIK. That's why I asked if you compiled with x64, which could (should?) bypass this thunking layer.
Ha, I'm glad I wasn't the only one who fell for this trap ;) Actually Windows 64 bit DLLs are in Windows\System32 and 32-bit DLLs are in Windows\SysWOW64
That's a very awkward compatibility layer you have there, Microsoft ;)
Source: https://stackoverflow.com/questions/1855042/system32-folder-on-a-64-bit-system)
I do not mean where the dll is located but what type of dll was loaded (x64 or 32). There are flags in the PE header that indicate that.
I do not mean where the dll is located but what type of dll was loaded (x64 or 32). There are flags in the PE header that indicate that.
It's x64.
I haven't figured out what exactly causes the crash so far, but I decided to skip it because each and every other plugin works fine for me.
I just have to figure out a way to detect the crash and handle it.