This project has moved and is read-only. For the latest updates, please go here.

Attempted to read or write protected memory

Topics: Audio, Crash, Debugging
Dec 1, 2011 at 5:23 PM

Hi all, just wondered if my experiences are common or if anyone else has come acoss this issue.

The fault occurs in void CallProcess32(float** inputs, float** outputs, ::VstInt32 sampleFrames) VstPluginCommandStub.h

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Whilst I am aware that plugins can be badly written, some of those failing work on VST Host

For some reason ?? it appear to be drum step sequencers that fail; quite a number of them !

Here's a link to a couple of  failing plugin that works on VST Host

I'm using PortSharpAudio and asio drivers.  I have many window7 64 bit ( compiled for 32)

The vsthost I've created plays many vsti synths as well as being able to use portshap at the same time for wav playback.

Any ideas how to track this one down would be appreciated

Regards Tony

Dec 1, 2011 at 9:38 PM
Edited Dec 1, 2011 at 10:02 PM

Yeah this can happen quite often.. I've fixed it in some ways but it's still a problem. Be sure to review all the unmanaged structures like VstTimeInfo , if the plugin ask for something in the callback function be sure to provide something. Also be aware that some plugin can crash if you access more than 2 audio ouputs or provide no input etc....

Besides that both synth you mention are synthmaker / synthedit assemblies isn't it? They aren't the most stable plugins.

Dec 1, 2011 at 9:52 PM
Edited Dec 1, 2011 at 9:52 PM

Here, this one might help in the host command stub :

        Jacobi.Vst.Core.VstTimeInfo vstTimeInfo = new Jacobi.Vst.Core.VstTimeInfo();

        public Jacobi.Vst.Core.VstTimeInfo GetTimeInfo(Jacobi.Vst.Core.VstTimeInfoFlags filterFlags)
            vstTimeInfo.SamplePosition = 0.0;
            vstTimeInfo.SampleRate = 44100;
            vstTimeInfo.NanoSeconds = 0.0;
            vstTimeInfo.PpqPosition = 0.0;
            vstTimeInfo.Tempo = 120.0;
            vstTimeInfo.BarStartPosition = 0.0;
            vstTimeInfo.CycleStartPosition = 0.0;
            vstTimeInfo.CycleEndPosition = 0.0;
            vstTimeInfo.TimeSignatureNumerator = 4;
            vstTimeInfo.TimeSignatureDenominator = 4;
            vstTimeInfo.SmpteOffset = 0;
            vstTimeInfo.SmpteFrameRate = new Jacobi.Vst.Core.VstSmpteFrameRate();
            vstTimeInfo.SamplesToNearestClock = 0;
            vstTimeInfo.Flags = 0;

            return vstTimeInfo;


Dec 1, 2011 at 10:38 PM

YuryK  I think you maybe onto something regarding the the structure in the callback that I was not even aware of !  All but one of the VSTis that are failing for me are drum machine with a step sequencer, so populating GetTimeInfo makes even more sense in that context.  I'll have a look in my lunch hour at work tommorow. I'm trying to keep my VSThost project seperate from my sequenecer workstation project that I work on at home.  I know if I intergate them now I'll spend too much time playing with all the great soft synth sounds rather than progress with the logic of the workstation

I can't believe all the vintage synth emulations there are.  I started building analog synths in 1981 as a teenager ('cos I couldn't afford to buy them), so for me, its like being a kid in sweet shop.

YuryK Thank you very much

Regards Tony

Dec 2, 2011 at 1:26 PM

Closer,  the one synth I had failing now works thanks to your fix :)

Howver I still get it crashing on any drumsynth step sequencer that work on VSThost

Here a link to another

They crash after play has commenceed  with or without any sounds loaded

Any clues, does the above drum sythn work for you or anyone else using vstnet  ?

Regards Tony

Dec 2, 2011 at 2:47 PM

This type of error is usually the result of some sort of memory corruption (as the error indicates ;-).

I have encountered such errors in the past where plugins wrote past the spec-ed string buffer lengths. Enlarging these buffers fixed those errors.

The fact that it occurs in Process doesn't mean much, other than that probably the AudioBuffers (pointers) were corrupted.

One way to find out more information is to turn on tracing for VST.NET (check out the Host sample config file).

That way you know what methods are used by the plugin (and the host - but you know that already) and narrow down the search.

Another way to find more info is to try those plugins in other VST.NET host applications. But those are scarce...

Dec 3, 2011 at 10:07 AM
Edited Dec 3, 2011 at 9:10 PM

The memory corruption is very often writing after the buffers or reading uninitialized vst structures. Otherwise, maybe the plugin is 'used' to get some marginal value from the host and you return an unexpected value that the plugin doesn't check and use to access directly memory by pointer arithmetic. Tracing every call and parameter values is something that might be useful at this point. The plugins you listed doesn't work for me either.

Oh and Tony cool to hear you were building analog synths before I was born :D

I also have a 44U modular analog synth and I'm quite proud of putting that beast together. Here is a picture of the machine, it should show up on the forum. Marc, sorry couldn't resist to get off topic :D

Image and video hosting by TinyPic

Dec 5, 2011 at 9:54 AM


Wow that a big one ! Well done.  I'll turn on tracing today and have a look.  It seems very curious that my host fails on all drum step sequencers, there must be something generic to them that I am not implmenting.  Do you have any working drum step sequencer plugins.  The one Im really trying to get going is its a TR808 clone.  The other options is for me to write my own, but Id rather not get distracted with that

Dec 5, 2011 at 1:37 PM

Hi YuryK  , obiwanjacobi

I have the answer to my problem which I thought I'd share. As you both pointed at it was an uninitialized  structure.  My failure was the assumption that output audio vst buffer would be (1) mono or (2) stereo. In fact the plugin  theDrumSouce has 24 outputs oops !.

Now i've corrected that all is well.

My next  issue is to work out why, on some plugins the editor does not redraw fully, but thats another thread :)

Dec 6, 2011 at 12:14 AM
Edited Dec 6, 2011 at 12:15 AM

Hi Tony,

Before starting a new thread try these steps:

Call these three functions 'getEditorSize', 'processIdle' and 'processReplacing' continually while the GUI is open.

If size don't change and you don't need to process audio call the functions anyway because plugins can rely on them being called frequently for their redrawing.

Dec 7, 2011 at 1:02 PM

Hi YuryK

Thanks for the pointer.  In fact all I had to call was  Jacobi.Vst.Core.Host.IVstPluginCommandStub.EditorIdle() which I do every 100 ms.  This works great ;)

Another issue that I have noticed and cured was another one of  'Attempted to read or write protected memory' during the dispose of a plugin.

This only occurs if you call  hostCmdStub.PluginContext.PluginCommandStub.Close(), before disposing of the plugin !

I suspect this is because when I traced the code invoking Dispose on the plugin automatically invokes l  hostCmdStub.PluginContext.PluginCommandStub.Close()


		if(PluginCommandStub != nullptr)

Since I now have a host quite complete I wondered if the sample projects are worth updating to include fuller featured host that can do playback save banks etc ?

Dec 14, 2011 at 7:57 PM

Actually, I'd be interested in your fixes. My host is also quite complete but you can never have enough fixes with those sleazy vst. If you mind, you can contact me at :

Apr 21, 2012 at 12:08 AM

Fabulous YuryK,

I've been tearing my hair out with corrupted memory using Largo; I was almost going to give up but having followed your example by passing back VstTimeInfo - the exception is gone.

Many thanks

Apr 22, 2012 at 10:21 PM

Glad it helped :D