You can try using ClientAPI v.1.1.0-rc1. It is revamped version of ClientAPI which is less prone to race conditions inside connection logic. It also provides more ways to know what’s happening with your connection.
When you create connection, you can specify callbacks for five events: OnClosed (when EventStoreConnection is completely closed because something very bad happened or reconnection limit is reached), OnErrorOccurred (some connection-wide error occured, should be very rare, if any), OnConnected (TCP connection to EventStore is established), OnDisconnected (TCP connection was closed), OnReconnecting (next try for reconnection is being attempted).
Please look at arguments they accept, some of them have Exception or string (reason) as parameters, that can give you a clue on what is happening.
Other possibility is that your EventStore is up, but still initializing, when you send read request. In that case the request will be ignored on server and you won’t ever receive any response. That is handled better in dev version of EventStore and handled appropriately in 1.1.0-rc1 version of ClientAPI, but if you are using <= 1.0.1 of EventStore – you should somehow make sure that EventStore is ready (is in working state) when you send requests.
When you are using EventStore in embedded mode (as it was discussed in few threads earlier) you won’t have this problems, because when you start node, you wait for BecomeMaster message on EventStore’s internal message bus, which ensures that node is up, initialized and ready to serve requests.
Hope that helps you.