LSP conflicts and IE crashes

I’ve written about troubleshooting client component issues with IAG in the past, and recently I’ve noticed some users running into a problem with LSP conflicts.

This problem manifests itself as IE crashes on the client, after connecting to the portal. The user would launch the portal URL, but after the IAG client components finished installing, the browser would hang or crash. Then, upon re-launching the browser, no website could be browsed-to, and that situation was only resolved by uninstalling the client components completely.

The cause for this is LSP conflicts. LSP, short for “Layered Service Provider” is piece of code (DLL) that uses Winsock APIs to insert itself into the TCP/IP stack. Then, an LSP can interact with internet traffic, such as the traffic that goes in the browser. An LSP could be, for example, a security tool that inspects the traffic before it reaches the browser, and filters out or blocks potential attacks. A system can have any number of LSPs, and when there’s more than one, they are registered in a certain order, and that could cause problems.

IAG’s client components are an LSP, and they are designed to be the sole LSP on a system. If another LSP is in place, it could cause an LSP Conflict, which would be seen to the user as the problem described above. Fortunately, LSP problems are easy to diagnose and resolve. To see a list of current LSPs, simple type this command in a CMD window:

netsh winsock show catalog type=lsp


Sample of a “good” LSP list

In the above screenshot, we see the result of a “good” output for the LSP list command, which shows only one LSP – IAG’s client components. If the list shows an additional entry, then good chance this is the culprit. In many cases, the cause of problems for IAG customers has been Windows’ built in parental controls, which are another program that is an LSP. When Parental controls are active, they might conflict with the client components and cause a problem.

When an LSP conflict occurs, the only thing one can do is to remove the offending LSP. This is done by gathering the catalog ID of the provider (1076 in the above screenshot, although it will be another number for other LSPs), and typing in this command in a CMD window:

Netsh winsock remove provider <Entry ID>

If the LSP is still loaded, it might require a reboot to get rid of it completely. If, for some reason, this command fails to remove the conflict, a utility called LSPFIX from can help as well. This utility will display a list of LSPs that have been found, and by clicking the offending one and moving it to the “remove” pane, one can get rid of it:


Word of warning, though! LSPs are not a burden – they are an important feature of Windows, and an LSP on your system might have an important function. Even if it interrupts your plans to use IAG, one must practice caution and think carefully before removing one. It may turn out that the LSP has an important function (even if you don’t personally recognize its name) and removing it may jeopardize your security to some extent. I recommend performing the above actions carefully, and creating a system restore-point prior to making changes.

Comments (3)

  1. Donnie says:

    I need help with this issue.  Who can I get to assist me?  

  2. ben ari says:

    Donnie, you can try the uag support forum on TechNet, or open a support case with Microsoft.


  3. LSP writer says:

    You make a huge assumption here that it is the 3rd-party LSP that is causing the issue and not UAG/IAG's LSP!

Skip to main content