Skip links

Dan Gough

Broken Database Connectivity in App-V Apps

In my previous post, I described an issue with an in-house developed app that was unable to connect to it’s database when running inside App-V. A few weeks later, different client, different app (Trojan CASPAR), and I encounter the issue again:

I fixed it previously by disabling the entire virtual registry at the package level; but this was not an option this time as there were vital registry entries in this package. And unfortunately I didn’t have any ‘network documentation’ to check. So, I busted out Procmon, but could not find anything that jumped out at me. Then I decided to give SpyStudio a whirl (which by the way is now available free of charge for the full version). The great thing about this app is that it lets you do two captures and compare them; so I did one with the app running natively, and one with the app running inside the bubble.

Straight away I could see a big block of different behaviour in green so I checked there first. The broken app was making numerous call to HKLM\System\CurrentControlSet\Services\WinSock2\Parameters:

The package did not contain any registry entries under this location, so I decided to add a passthrough path so that the App-V client directs all reads and writes to this key directly to the real registry, bypassing the virtual registry entirely. UnderHKLM\Software\Microsoft\AppV<wbr>Subsystem\VirtualRegistry is a multi-sz value PassThroughPaths that lists all the keys that bypass the virtual registry. I added this WinSock2 key here, closed and restarted the app, and it could then connect without a hitch!

So, next step is to automate applying this key via an App-V script. I stuck with vbscript for this since I already had a script in my toolbox to do the job for handling multi-sz registry key. Save this as AddWinSock.vbs under the Scripts folder of the App-V package:

I did not add a RemovePackage equivalent to undo the change just in case there ended up being multiple apps requiring this fix then removing one could break the others. But if you want to implement it, the function to do so it right there in the vbscript. Changing this key affects all packages on the client however. So, unless you can find a package that contains and requires entries under the WinSock2 key, which I have not yet come across, then this should be safe to apply - but of course use this at your own risk!