In your second screenshot you see that the server sends its ServerHello and no subsequent Certificate Request... but no Certificate either. The server immediately proceeds with a ChangeCipherSpec, as if all the asymmetric crypto had already been done; and that's exactly the case. This is an abbreviated handshake in which both client and server remember the session secrets from a previous connection, and agree to use them again. When a session is thus resumed, there is no certificate, neither from the client, nor from the server. The client sends in the ClientHello a copy of the session ID from the previous session, and the server elects to indeed resume that session.
Ideally this is fine; if the previous session used an authentication that the server is comfortable with (e.g. a client certificate was indeed shown), then reusing the session implies reusing that authentication state. If the server is not comfortable with it, it may reject the resumption attempt (i.e. ignore the session ID as sent by the client, and proceed with a full, normal handshake) or enforce a re-handshake within the first. In a practical, realistic World, things are not always ideal, so the server code may accept to reuse the session, then decide that it should not have done so, and hide its shame by abruptly closing the connection.
SSL session parameters are cached in RAM, so restarting the client and/or the server process should empty such caches and at least allow you to obtain a clearer picture of what happens. It might also fix the issue altogether (that's the lightweight version of "try a reboot", a well-known cure for many Windows-related ailments).
