This is mostly likely not a SQL server issue but the setup seems to only be affecting BULK INSERTS to SQL Servers.

We have recently moved VM Hardware and all the guests that were moved had their virtual switches changed from standard to distributed.

I then started receiving

A fatal error occurred while reading the input stream from the network. The session will be terminated (input error: 64, output error: 0)

on a two SQL servers during BULK INSERT operations. One of the SQL servers was a VM with the new configuration and the other was a physical server. Both BULK INSERT operation originated from a VM with the new configuration. The BULK INSERTs would not fail every time, it was very random when it would.

When we changed the virtual switch to be a standard switch instead of a distributed switch the issue goes away.

I am looking for more of an explanation to why it doesn't work with a distributed switch instead of a resolution. My guess would be that the BULK INSERT operation is serial and with a distributed switch the packets are being routed through different hosts, some of which may be busier than others, and are arriving at the destination server beyond some latency threshold. (note: there is nothing in the windows event log at the times of the errors on either the source or destination server)

UPDATE: turns out the issue was due to the NIC. All of our VMs were configured with an E1000 NIC which functioned well enough on standard switches. Once we moved to distributed switches, we started seeing issues with large data transfers, not just sql queries. Changing the NIC to VMXNET3 seems to have resolved the issue.

  • Is VM showing any errors? Commented Jan 18, 2013 at 16:55
  • No error on VM guest or host.
    – Bob Klimes
    Commented Jan 29, 2013 at 14:38

3 Answers 3


Pure vmware/networking issue, it appears.

I suggest trying to find a connectivity problem from the clients to the server that is not SQL (ping, or anything). That will help you surface a clearer troubleshooting path.

  • It does appear to be a vmware issue as I can recreate behavior with a large file copy
    – Bob Klimes
    Commented Jan 28, 2015 at 20:29

I would suggest using Wireshark or Microsoft NetMon and sniffing the traffic to see what is happening here. Could also be related to the TCP Chimney Offload feature, assuming something has changed at the NIC level:



we have experienced this error a week ago. our network team, security team and database team search every thing. At the end of the researching we have detected the error resource. It is the IPS device. Ask your security team is there any signature on IPS device.

  • Which IPS device? How does your environment compare to that of the asker and how will it solve his problem? Commented Nov 5, 2014 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.