Some weeks ago we had an interesting error report from a user. He reported that several times a day his SAPGUI crashes with the message “WSAECONNABORTED: Software caused connection abort”. We did the usual procedures when it looks like a network problem (new NIC drivers, new LAN cabel etc.) all to no avail.
At the time we showed up at his desk the third time (now with a LAN tester), a colleague of him also reported he has this error but only once every three days. Investigating further, it turned out that nearly all our users had seen this error at least once, but in a different frequency (several times a day up to once in two weeks).
Now this small problem just got promoted to a huge problem! Checking SM21 (Syslog) confirmed that we really had an issue.
I will now just skip the part where we have tried several Voodoo tactics to isolate the problem (DPC storm? Energy Options? TCP/IP Auto Tuning options?) and go straight to the cause.
Every time the user has reported the error, the Windows event log showed an entry inside “Network Profile” (Event Viewer –> Applications and Services Logs –> Microsoft –> Windows –> NetworkProfile) that a network identification is taking place (Event IDs 10000, 10001 and 4002). However, the computer was connected all the time so this shouldn’t happen.
Since we also have a the Windows firewall running and active, it was clear what happened: For some reason Windows thinks it needs to identify the network which triggers the Firewall to cut all connections.
This happens since the network is in the state “Unidentified” during identification. Since all our firewall rules either required the “Private” or “Domain” profile, no rule was active that permitted any data transfer and this caused all existing connections to be closed. Thus, SAPGUI displayed “WSAECONNABORTED: Software caused connection abort”.
Turning the firewall off is no solution, so we concentrated on fixing the unnecessary network identification. Monitoring Network Location Awareness (NLA) we saw that DHCP was causing a lot of messages that indicate a network identification should take place (If you want to verfiy this, see this blog post for more information about monitoring DHCP).
Therefore, the first thing we then did was to disable any network connection that was not needed, like “Microsoft Virtual WiFi Adapter”, “Bluetooth Network” and so on. This helped, but for some users the error still existed.
A case at Microsoft then revealed hotfix KB2524478 which solved this issue once and for all.
Victory! :-)
Poor man’s SEO ;): Windows 7 intermittently drops network connection networking random disconnects Windows 7 networking drop connection Windows 7 frequently randomly disconnects Windows 7 network dropouts