Why MySQL Connector/NET Randomly Fails Authentication and How to Fix It

Problem Description

In a Windows application using MySQL Connector/NET (version 6.9.9), occasional authentication failures occur with the message: “Authentication to host 'xxxx' for user 'yyyy' using method 'mysql_native_password' failed with message: Reading from the stream has failed.”

Symptoms

Only the .NET Connector exhibits the problem; JDBC works fine.

Among multiple application servers, only one shows the error, ruling out server‑side issues.

The error appears randomly; restarting the server/IIS temporarily clears it.

Even on low‑CPU servers the error can still surface.

Analysis

Packet captures on both the application and database sides show identical traffic, eliminating network loss. The first three packets are the TCP three‑way handshake. The failure originates at the sixth packet, where the MySQL server sends a FIN packet because it has detected a connection timeout controlled by the connect_timeout variable (default 10 seconds). The gap between the fifth and sixth packets is exactly 10 seconds, indicating the client did not send any data within that window.

Comparing a normal connection trace with the faulty one reveals that after the client sends packet 5 (which should immediately carry the authentication payload—username, driver version, OS details), the driver delays this payload. In the faulty trace the payload is sent only in frame 8, by which time the server has already closed the connection and subsequently sends a RST packet (frame 9).

Investigation of the driver code points to MySQLAuthenticationPlugin.cs, where the OS information is obtained via a WMI query ( GetOSDetails()). Timing instrumentation added to this method shows a ~30‑second pause, all of which is spent retrieving the Caption property via WMI.

Root Cause

The slow WMI query for OS details blocks the authentication handshake for more than the server’s 10‑second timeout, causing the MySQL server to terminate the connection and the driver to report the authentication failure.

Verification

A minimal reproducer extracting the WMI call was executed on the problematic server. The logs captured during the test show multiple instances where the WMI query exceeds 30 seconds, confirming that the delay is the direct trigger of the authentication error.

2017-11-21 17:19:30.208,       33638
2017-11-21 17:20:09.193,       33199
2017-11-21 17:20:53.086,       33201
... (additional timestamps omitted for brevity) ...

Solution

Since the OS information is static, the driver should cache it or obtain it from environment variables instead of performing a WMI query on every connection. Commenting out the WMI call or replacing it with a cached value eliminates the >30 second pause, prevents the timeout, and improves Connector/NET performance.