Go ahead, keep BING'ing...I'll wait.  


Now that you confirmed all COM Surrogate errors are NOT resolved by adding the DLL's to the Data Execution Prevention (DEP) list, perhaps I have a solution.  Before we proceed, please, PLEASE remove COM Surrogate from your DEP exclusion list if it's already added.  Adding anything to the DEP list can create a rather clumsy security risk.  COM Surrogate; however, should never be excluded.  If you have COM Surrogate errors, you have something going on that is worthwhile to investigate.  The solution is not to curb the error.

I fired up my laptop the other day to configure a router for a friend.  I changed the IP settings of the LAN adapter on my laptop.  When I clicked "Close", the Network and Sharing Center locked up, only to be immediately followed by a COM Surrogate error.  I could close / acknowledge the error prompt, but the Explorer windows for the network settings was locked up.  I was surprised by the error, as I keep my laptop is good health.  But when the error kept happening, I started getting annoyed and at this point, I am fully engaged in resolving the bug.

First things first...review the Event Logs.  Chances are there is a reference to the error in either System and/or Application Logs.  Depending on the error, the Event Logs may not have enough information.  A better option for this issue (or most driver related crashing) is to use the Reliability Monitor.  Open the "Action Center".  Click "Maintenance" then the "View Reliability History" link.  It may take a moment to generate a report if no recent report exists.  Once displayed, click the "View All Problem Reports" link at the bottom.

Locate the "COM Surrogate" errors as well as dates and times.  Ensure you are looking at the correct error.  (One at a time, right?)  "Right-Click" the error and select "View Technical Details".  Finally, you should now see the details regarding the error.  (For kicks, always try to check for a solution automatically first.  When that doesn't work, review the problem details.)  Notice the "Fault Module Name".  In my case, the file is "netcfgx.dll".  I naturally went to the Internet to investigate the DLL file.  Surprisingly, I found very little of the source of the file.  A few references to possibly video drivers, but nothing conclusive.  Being the file name has "net" in it, I leaned towards network drivers instead.  (crazy)

Uninstalled the adapter, re-installed the adapter, installed new drivers, installed even newer drivers...I wasn't getting anywhere.  I have already exhausted typical TCP/IP Winsock resetting (netsh int ip reset c:reset.log) and a System File Check scan (sfc /scannow).

Luckily my Wi-Fi connection is working fine, allowing to save time with troubleshooting.  But wait!  Why is only my LAN adapter affected?  Looking closer at the two adapters, side by side, I noticed the adapters have "Deterministic Network Enhancer" (DNE) installed.  While it's not causing issues with the Wi-Fi adapter, DNE is often associated with VPN software.  Well I only have one third party VPN solution installed and that is the SonicWall Global VPN Client.  I also know that I have encountered issues with this VPN client on multiple occasions.  Knowing what I know from experience, I still didn't want to blame SonicWall.  So two System Restores later, well... two tears in a bucket...  I uninstalled the VPN client.  Guess what, RESOLVED!

My only guess is that the SonicWall VPN Client integration into the adapter became corrupt.  In fact, I encountered an error when uninstalling the client.  Simply clicking uninstall a second time, forced through the error, uninstalling completely.  I have since re-installed the VPN client and so far, so good.

I should note that shortly into troubleshooting the issue, before driver changes and restores, my friend told me to uninstall the SonicWall VPN software.  There was limited (at best) logic to this at the time, AKA, he had a hunch.  Remember in Math class you had to show your work?          ...Meh