VSTPluginContext Dispose issue about vst.net HOT 17 CLOSED

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).

from vst.net.

Do you have a stack trace?
The error code 1073741855 does not ring any bells...

from vst.net.

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.

from vst.net.

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.

from vst.net.

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.

from vst.net.

That is disturbing...
Have any idea what the problem was, any stack trace?

from vst.net.

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 ;)

from vst.net.

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

from vst.net.

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.

from vst.net.

Did you build Jacobi.Vst.Samples.Host with x64 or AnyCpu?

from vst.net.

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 ;)

from vst.net.

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

from vst.net.

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.

from vst.net.

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]

from vst.net.

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)

from vst.net.

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.

from vst.net.

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.

from vst.net.