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:

Error

SQL Database Logon Error

Form: FrmUserLogin

Procedure: Open database

Error Code: -2147467259

Description: [DBNETLIB][ConnectionOpen (Initialize()()).]General network error. Check your network documentation.

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:

SpyStudio

 

The package did not contain any registry entries under this location, so I decided to add a pass through 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. Under HKLM\Software\Microsoft\AppV\Subsystem\VirtualRegistry is a multi-sz value PassThroughPaths that lists various 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 it’s simple to use, and I already had a script in my toolbox to do the job! Save this as AddWinSock.vbs under the Scripts folder of the App-V package:

Then I added this to DeploymentConfig.xml under an AddPackage trigger:

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!

 

10 responses on “Broken Database Connectivity in App-V Apps

  1. Andrew Gallucci

    Very interesting. But if the package didn’t contain these keys why was this getting ‘stuck’ in the client? Bug??

    SpyStudio looks like a cool thing looking forward (while also not looking forward) to debugging with it.

    1. Who knows! Some strange bug… I didn’t inspect the logs in depth enough but perhaps it was trying to do something unsupported to the registry key – for example mounting a .dat hive or trying to change registry key permissions would both fail.

  2. Roger

    Hi Dan

    Just want to say thanks for sharing your experience. I spent days with troubleshooting a network app with same database logon error…without luck.

    After reading this article I was now able to resolve the issue 🙂

    1. No problem, glad it helped – if it was a common of-the-shelf app, please let us know what it was for future reference!

  3. Najath

    Hi Dan

    Thanks for this! Had the same issue with another in-house developed app. Procmon was full of winsock2 calls. Adding the pass through paths solves the issue.
    I then used your VBS in the package and it works perfectly!

    Thanks a million. 🙂

  4. John Gordijn

    Hi Dan

    Since july this year we suddenly got this problem with at least 3 different sequences that were working just fine. The problem only occurs with users that havent got those applications published before july.
    Have you ever discovered the reason for this problem? We have a feeling that something has changed on our Windows 7 workstations (hotfix?) but have no clue where to look.

    1. Check the version of C:\Program Files\Microsoft Application Virtualization\Client\Client.exe and make sure they are at the same hotfix level (look up the versions here).

      Perhaps the fix was applied to the registry in the past and a hotfix undid the change?

      1. John Gordijn

        Hi Dan

        Hotfix lvl’s are all the same. The registrykey you mentioned is set in our environment by GPO so no changes are possible.
        We even have the situation with 2 different users on one PC of which one has the problem and the other hasnt…

        1. Very strange if it’s user-dependent. I would try repairing the App-V package for both users to eliminate anything in the user layer (or repair the connection group if they are a member of one), and temporarily disable any user profile management services such as UE-V or AppSense and re-test.

          1. John Gordijn

            Hi Dan

            If we repair the application the problem will still be there. We dont want to do this for a user that hasnt the problem yet because we are afraid we might break things.

Leave a Reply