MySql exception on Windows 10: SocketException with ErrorCode 10053

Question

I have a small application which is trying to import data from a MySql database into a SQL Express database. This is under development in Visual Studio 2013 on Windows 10, using Entity Framework Database First to model the MySql database, connect to it and retrieve the data.

The software is being developed TDD, so I have an NUnit test which is checking that the application can successfully connect to the MySql database and retrieve data from it. One test is very simple, as follows:

[Test]
public void MySqlContext_CanConnectToLegacyDb_OpensWithoutErrors()
{
  // Arrange
  using (MySqlContext legacyRepository = new MySqlContext())
  {
    bool exceptionThrown = false;
    List<string> exceptionMessages = new List<string>();

    // Act
    try
    {
      legacyRepository.Database.Connection.Open();
    }
    catch (Exception ex)
    {
      exceptionThrown = true;
      exceptionMessages.Add(ex.Message);
      while (ex.InnerException != null)
      {
        ex = ex.InnerException;
        exceptionMessages.Add(ex.Message);
        if (ex is SocketException)
        {
          exceptionMessages.Add(string.Format("ErrorCode={0}", (ex as SocketException).ErrorCode));
        }
      }
    }

    // Assert
    StringBuilder errMsg = new StringBuilder("Exception was thrown: ");
    foreach(string em in exceptionMessages)
    {
      errMsg.AppendLine(em);
    }
    Assert.IsFalse(exceptionThrown, errMsg.ToString());
  }
}

Ie. it is simply checking that it can open the connection to the MySql database without any exceptions being thrown.

This test is failing. The attempt to open the MySql database produces the following exception:

Result Message: Exception was thrown: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. An established connection was aborted by the software in your host machine ErrorCode=10053

Expected: False But was: True

MySql is running on the same machine as this test and of the application that it is supporting. It is in use by other software on the machine, including MySql Workbench and the Server Explorer of the same Visual Studio instance, without any connectivity problems. I have checked and re-checked the connection string being used to access the database, and it is the same one that was generated by Entity Framework when it generated the model for the database.

Based on what I've read about this exception online, I have made a thorough check of all of the security settings on Windows 10, I have reviewed MySql logs and other logs, including the Windows event logs. I can find nothing in any log which hints at what is aborting the connection with MySql. Fiddler does not show anything when the offending line of code fails, so I can see no evidence of anything trying to talk to MySql via the localhost/127.0.0.1 connection.

I've tried disabling those settings that I can find, and disabling by BitDefender anti-virus software, and none of those actions has any effect on this error.

What else can I check, to find out the cause of this error? Could it be a security setting within Windows?

Some further information: Prompted by something I read elsewhere about EF Database First, I tried deleting the MySql model from my solution and re-adding it, to see if this changed anything in the connection string. This time through, the ADO.NET Entity Data Model wizard dies, with no errors, when I click Next on the Choose Your Data Connection screen (3rd screen). When it does this, the Server Explorer connection to the MySql database closes (the icon shows a red cross, when it was showing a green plug).

I'm now thinking that there is some configuration problem, somewhere in my solution. But how to diagnose the problem? I get no error messages, when the wizard dies, and the Output window shows nothing.

Another update: I think the problem might be down to MySql configuration issues. I appear to have 2 or possibly 3 "my.ini" settings files for MySql, and I suspect that the one being maintained by the MySQL Workbench is not the one that the server is actually using for its configuration. Why do I think this? Because, when I enabled logging for various items that are not logged by default (why not?), no change in behaviour happened. MySql did not begin writing log files - until I copied the my.ini file that had been changed by the utility (C:\Program Files\MySQL\MySQL Server 5.5\my.ini) over the file that was in C:\ProgramData\MySQL\MySQL Server 5.5. After I did that, MySQL started logging stuff, but then I could not connect to the server properly via the Workbench.

I am investigating further, and will post what I find here, in case anyone else has a similar problem.