LSP Installation Problems with WSCInstallProvider64_32

  • Article

An LSP (or Winsock provider) can be installed into the Winsock catalog through several different function calls. Also, as you might know, on 64-bit Windows there are two different Winsock catalogs – one for 32-bit applications and one for 64-bit native applications. In order for an LSP to be loaded by both native and WOW64 applications, it must be installed into both catalogs. There are two ways to install a Winsock provider into both catalogs:

1. Call WSCInstallProvider64_32 which installs the same provider entries into both Winsock catalogs

2. On Vista, call WSCInstallProviderAndChains which performs all the necessary steps but results in separate install calls to the 64-bit and 32-bit catalogs

Each of these functions will install the provider information into the appropriate Winsock catalog. The Winsock catalog is a repository in the registry that contains information about each Winsock provider. For 64-bit Windows, there are two versions of the catalog – one for native 64-bit applications and one for 32-bit applications.

Unfortunately WSCInstallProvider64_32 works in only a handful of cases. The basic problem with this function is it attempts to install the same WSAPROTOCOL_INFOW structures into both Winsock catalogs. This means that the protocol chains specified in the WSAPROTOCOL_INFOW structure will contain the same catalog IDs for both the 32-bit and 64-bit Winsock catalogs. However, if a Winsock provider was installed either into one but not both catalogs or if the Winsock provider was installed into both catalogs using methods #2 then the catalog IDs in each of the two Winsock catalogs become out of sync.

For example, one way the catalog can become out of sync is if an LSP is installed only into the 64-bit catalog. That is, the application installs an LSP provider which will be assigned the next free catalog entry ID – say 1020. Then another LSP is installed using WSCInstallProvider64_32. This LSP installer builds a protocol chain and layers its entries over the first LSP that has the ID of 1020. Since WSCInstallProvider64_32 installs the same WSAPROTOCOL_INFOW into both catalogs, the 32-bit Winsock catalog now contains an entry that references provider 1020 which does not exist in the 32-bit catalog. This would result in the loss of network connectivity for 32-bit applications.

For Windows Vista, if WSCInstallProvider64_32 is called and the 32-bit and 64-bit Winsock catalogs are not in sync, then the call will fail with WSANO_RECOVERY.

Because of this it is recommended that LSPs move to the WSCInstallProviderAndChains function on Vista which takes this issue into account (as well as saves you from writing and maintaining the ~600 lines of code to perform all the install steps). Of course, for downlevel Windows OSes, WSCInstallProvider64_32 is the only method for installing an LSP entry into both catalogs. The current LSP SDK sample dynamically checks if WSCInstallProviderAndChains is available and uses that; otherwise, it falls back to using WSCInstallProvider64_32. The latest sample is available from https://connect.microsoft.com/wndp.

--Anthony Jones (AJones)