Всем привет. Подскажите, пожалуйста, как определить причину разрыва SSL-соединения?

Клиент генерирует 250 HTTPS-запросов и параллельно отправляет их серверу. На N'ом запросе получает сообщение о том, что базовое TCP-соединение было закрыто сервером.
The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

На сервере же Wireshark показывает такую пакость:

	1313 12:57:36.300285000 172.16.1.61 172.16.12.232 TCP 60 443→53531 RST, ACK Seq=19756 Ack=4544 Win=0 Len=0

Пожалуйста, подскажите: как определить причину разрыва соединения?
До обработчика запрос не дошёл (во всяком случае, в логи не попал). Вероятно, рубит его ОС (Windows 2012). Возможно, связано с максимальным количеством SSL-соединений или TCP-соединений или ещё каким-нибудь системным параметром. Может, какая-нибудь защита от DoS-атак и т.д. Подскажите — в какие логи смотреть, как и чем ловить инициатора разрыва? (Без отладки в Kernell mode).

Также замечено, что на одном из серверов падение происходит уже при 10 запросах. А на другом — только после ~150го.
Возможно, это наведет на светлые мысли о причинах разрыва?

Буду рад ценным советам.

UPD:
Посмотрел по стеку — оказывается, вначале сервер посылает FIN, а уже затем, в ответ на новую порцию SSL'я, RST.

	1311 12:57:36.299287000 172.16.1.61 172.16.12.232 TCP 60 443→53531 FIN, ACK Seq=19755 Ack=4139 Win=64512 Len=0

UPD:
Дешифровал трафик. Перед самым падением остался зашифрованный пакет. Беглый поиск подсказал, что такое происходит в тех случаях, когда не указана длина содержимого и WS не может определить объем шифротекста. Однако я вижу эту информацию внутри пакета. Быть может, именно этот "плохой" пакет как раз всё портит?

	12234 12:57:36.271405000 172.16.12.232 172.16.1.61 TLSv1 507 SSL segment of a reassembled PDU

UPD:
Ага, судя по всему был отправлен лишь фрагмент сообщения, после чего прилетел [FIN, ACK], поэтому его содержимое посмотреть не удаётся.
В TLSv1: Length: 448

В SSLStream:

sdk HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.18444)
VsDebuggerCausalityData: uIDPo00Ld7mK/bNPvA5t7hnOS1YAAAAAD8RtG09U7EucE0H7pfvq3xYbTOEHHmtLpu98ICcj7ooACQAA
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:vim25/5.0"
Host: vcdev55
Cookie: vmware_soap_session="52d41e69-2ef3-4c6f-8e9b-cc7b747b5e50"
Content-Length: 368
Expect: 100-continue

Говорят, что заголовок "Expect: 100-continue" — это не очень хорошо и у некоторых товарищей приводит к генерации ошибки на стороне сервера. Так ли это?

UPD:
С Expect: 100-coninue разобрался. То есть на очередной запрос "а можно мне чего-нибудь отправить?" нам дают отлуп. При этом этот отлуп игнорируется и данные мы все равно посылаем, за что получаем по носу и RST. Возвращаемся к вопросу — кто рубит коннекцию (какая служба, драйвер, программа)?
Если верить статье по ссылке, у команды маленький таймаут на выполнение — 350 мсек, но, если верить WS, в него я укладываюсь: