Wwise won't open in computer lab; asks to repair Visual C++ 2013

Question

We are experiencing problems getting Wwise to work in a computer lab.  The computers are loaded via disk image and students can sign in to a private account to access their files.  During initial testing, Wwise seemed to work fine.  However, now there is a problem when upon opening Wwise a dialog window pops up for Microsoft Visual C++ 2013 which gives the option to repair or uninstall.  If I click repair, nothing seems to resolve; the dialog window closes and Wwise closes.  If I try to open again, I'm presented with the same dialog.  This happens on multiple accounts.  We tried resetting my Mac profile and that worked temporarily,  but trying to open Wwise on another machine with my profile seemed to cause the problem to resurface.

Has anyone else run into this issue?  Any advice on how we might resolve it would be greatly appreciated.

Answer 1

Hello Paul,

This looks like a permission issue. Can your student accounts write to ~\Library\Application Support in the disk image ?

When a Mac authoring is opened for the first time, the Microsoft Visual C++ 2013 redist are installed in a Wwise folder (or Wwise2016 depending on your version) for the current user under YourUsername\Library\Application Support.

The non-persistence of that folder that is necessary for each user on the machine might be the issue.

Let me know if this helps !

 

Comments

Hi Fabian,

I appreciate the reply.  Was just about to post the following:

Our Computing Services team believes that this issue is related to the way that Wwise runs on a Mac—i.e. in an emulated Windows environment called Wine.  As I understand it, the problem is when the "bottle" (the container that holds the emulated copy of Windows) is copied on the initial login and allowed to roam.  The workaround they've proposed is to exclude the bottle at login to prevent it from roaming.  After this workaround is implemented, users must login on a computer they've never used before since any computer they've already logged into will have a profile with a broken bottle structure.  Alternatively, the computers can be reimaged, which would erase any local files.

Anyway, I'll run your response by our team tomorrow and see what they say.  Cheers!

---

Our team's response, in paraphrase:

Students have write access within their profile so it's not a permissions issue.  Since the Mac has no real equivalent of a roaming profile, we approximate one by manually copying things locally from the user's profile filestore whenever they log on, and then copying those same things back up again on logoff.  Not everything is copied because particular things don't tolerate being stored on NTFS and come back broken, so we implement a list of exclusions. In this case, we have added ../Application Support/Wwise2016 folder to the exclusion list.  The Wwise2016 subtree is full of symbolic links, which are particularly problematic for our copy-up/copy-down process.  Previously, logging off meant copying up most of a user's Wwise2016 subtree, but excluding the symbolic links. Upon logging on again, everything copied up would be copied back down, minus the symbolic links. Consequently, Wwise was unable to find the things that should have been down those links, and therefore would break.

It would be great to see a version of the Wwise authoring app that could run natively in OS X sometime in the future, but hopefully this workaround will be helpful now for those in the same boat.

---

Did this solve your problem
We are experiencing the same issue