Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Virtualization Community Blog

Side-By-Side Errors and SVS

Created: 19 Jun 2008 • Updated: 29 Jul 2010 • 2 comments
Jordan's picture
0 0 Votes
Login to vote

I've been doing a lot of work on AutoCAD and Inventor 2009 this past week and I kept on hitting a side-by-side error when I tried to export from XP to Vista or Vista to Vista (curiously it worked from XP to XP.) After some work I've found what the problem is and thought I'd share this since I've seen people in the past asking bout side-by-side errors.

Simply put a side-by-side error occurs when a shared DLL isn't properly registered with the system, this can be a manifest issue or an environmental variable issue (like the path not getting saved so Windows doesn't know where the DLL is).

The biggest culprit for side-by-side errors is Microsoft's Visual C++ runtime missing from the OS, and in the case of SVS that runtime doesn't capture properly which leads to the side-by-side issue. If you install the Visual C++ redistribute (in AutoCAD's case it's 2005) to the base of the capture machine before you run your capture and then install the runtime on the import machine everything should work fine.

I suspect this is also the cause of side-by-side errors with Visual Studio when it's captured in a layer.

Comments 2 CommentsJump to latest comment

Stjepan Baric's picture

Hi Jordan,

I am running into the same error during virtualization of several apps. Figured out that the problem is caused by missing or corruped C++ libraries. But in my case a simple import or installation of the "needed" C++ libraries isn't going to get the the main app running. Tried it with the Mindjet MindManager Viewer v7 but i got the same error every time. I'm using two exactly identical Windows 7 x64 packaging environments which are as far as possible plane. Means > only software installed inside of the virtual machines is:

- Symantec Workspace Virtualization Agent v 6.4.1603 (with GUI)
- VMware Tools v8.8.4.14177
- MS Visual C++ 2008 Redistributable x86 9.0.30729.4148
- MS Visual C++ 2008 Redistributable x64 9.0.30729.4148

Packeging the MindManager Viewer in one VM and exporting it (without user data of course) to the second VM which has the same setup. Getting the side-byside error! I just simply can't export the layer even if its working inside the first VM (multiple deactivation/activation possible). Looks like something gets lost during capture of the MindManager Viewer. Same problem if I'm using global capture. Everything works fine inside the VM which is used during capturing. Not working after export to another VM. Maybe there's something I am missing? I'm reverting my VM's every time after creating an layer so that there can't be any interference.

Would be great if someone knew a solution for my problem.


Login to vote
Nicolas Horchower's picture


Any update on this point ? I've read that some people were copying the winsxs folder in the layer. Is it a good idea ?

Is there a tool to correctly do this ?

I've done some tests, I was able to identify the ID used by the software to load the DLL, it is the publicKeyToken logged in windows application event.

Then I'll try to copy all the folder and the manifest in the layer. I've found that winsxs\Manifests is read only. I haven't try to overcome this. I then started the sxstrace tool. I finally was able to identify each DLL used by the software. I've copied all the files to the application folder. Saddly some DLL were referenced with a FQDN name com.xx.xx.xx.xx.dll, so I've made a copy of each DLL with the required name in the applicaiton folder.

IE: First you must deactivate the layer before copying file to RO folder/layer then

symantec.bigthing.dll (is the original file found in winsxs\xxxxxx-publicKeyToken-xxxxxx)
I've copied it to the application folder in the RO layer

sxstrace output give me the "internal name" of the dll :
So I also made a copy of symantec.bigthing.dll to

You need to do this for each DLL, then you re-activate the layer, and it works

I'm quite sure that there's a better way to handle this. As we have all the files (including manifest and .cat files) on the capture machine, we should be able to script this process ?

I wasn't able to find the procedure to import the manifest in the winsxs folder from CLI. I was hoping to find a way to "refresh" the sxs registry at activation step and do the same thing when we deactivate the layer (like with printer driver virtualization).



Login to vote