synopsos has to do with the syncrosoft driver I think. it may not get along with something protools installs. ie., the error probably means the OS is not accessing the process. historically pro tools drivers have been troublemakers in a sandbox. you aren't going to have much luck with a synsopos problem.

it would certainly be best to have the most robust machine as a slave and handle instruments, all instruments you can, and all FX you can. I write via mouse to certain GUIs so I don't do 100% in VE Pro but close to. I think particularly with PT, put everything you can on another machine than.

are you by chance running the network dynamically? 

the only experience I have resembling yours was when I was networking dynamically. 

there is corruption in your system, and probably more than one thing. crash on load following crash on save to me indicates corruption in the project or metaframe. It seems like this accrues when stressing an unstable situation.

dynamic as opposed to fixed/static [IP address]. if you don't know, in all probability you have settings = dynamic. all of this unpredictability IME points to that [as a primary problem]. it must be fixed, ie., you enter the address yourself, one for each machine.

go into system preferences, network > Ethernet tab > Advanced tab. 'configure IPv4 manually'.

I recommend you sort that first.

then in the VE Pro preferences > plugins, 'scan'. there is no good reason it doesn't recognize the EW stuff after that.

 This entire post is very strange.

I have a smaller system compared to this very impressive one, and yet VE Pro runs absolutely flawlessly on it.  I have never had a crash from simply loading and playing, even with large orchestral setups.

So I think this sounds like this system which is listed here is far too complex, and has some bugs in it due to conflicts between software.  Using default installations can cause problems, depending on what apps are being used. 

I would suggest totally re-formatting one slave machine and installing on it only VE Pro (and whatever audio/midi equipment you use), since this is not a money problem. Thereby create a computer totally dedicated to VE Pro as a slave.  It is far more useful than any of those other libraries you list, and so it would make sense to do that.   It is totally stable when not interferred with by other software.  I can attest to that having a system that has never had any problems such as what you report.  Then, if you use many other sample programs, install those on a separate slave(s) and let them do whatever they want to do. 

There is no instability normally.  I know from experience that various pieces of software can conflict, so that is the only thing I can suggest.  Perhaps to analyze - which of the libraries are essential, which are unnecessary, and then re-image and re-install only those that are really needed. If you look at orchestral - almost everything is VSL.   Also making sure you have the latest drivers/versions on all, though you probably already did that. 

Regarding your issues w/ PLAY, although it may sound trivial I don't believe you have indicated this among your configuration description, so- can you confirm that the PLAY version is x64 and not x86. Likewise, that VEP5 on the slave is x64 and not x86.

@avonkorff said:

VE Pro doesn't recognize "Play" as a valid plug-in add to a vframe.

and, once installed Play it runs a memory server at all times (actually if the only Play installed are versions since it went x64, I don't know why it would use one), which does not co operate with the Kontakt Memory Server if it is running in VE Pro. that combination will crash VE Pro per se.

@avonkorff said:

In your experience would it be better to run these memory-intensive instruments from our slave rather than the Pro Tools machine? Won't that put additional strain on the LAN connection between Host and Slave; potentially cause a bottleneck type issue?

how married are you to Pro Tools? It is probably not the best host for VE Pro use; have a look around here...

  I would recommend decoupling VEP from PT.

The notion of the LAN itself being the bottleneck is based on what exactly? I think it is a bad premise. BUT as I pointed out if you are running a dynamic network, it is changing addresses on you randomly and that is more than a bottleneck, that is a situation that will never work properly.