IIS 7 and Above
Error (randomly) 0x800703e3 on Windows Server 2016
Last post Oct 02, 2017 02:01 AM by mahamr
Sep 11, 2017 07:22 AM|omeganet05|LINK
We have a WCF app running on IIS on Windows Server 2016. Everything works fine until we realized some requests fail with status code 500. I set up failed request tracing on IIS and realized IIS responds with following error:
The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)
There is not much on the Internet about this error. I found some older sources pointing to a Windows Server 2008 bug, but I would doubt it is the case. Has anyone else experienced this? What other things I could do to troubleshoot this issue?
Sep 11, 2017 11:59 PM|lextm|LINK
WCF has its own tracing. IIS failed request tracing is useless here.
Sep 12, 2017 02:21 AM|Yuk Ding|LINK
Did you enable the ssl for your WCF service? I only find that it could be related to SSL certificate. Maybe you could try to disable SSL to ensure whether it is an SSL issue.
Sep 12, 2017 08:55 AM|omeganet05|LINK
Yes, we do have SSL and Accept for client certificates. The thing is we have two clients for our web service: a Java client providing a client certificate and .NET client using SSL only. We are experiencing the issues only with the Java client, and again,
it happens once in a while. I will try to enable SSL3 and WCF tracing.
Sep 20, 2017 08:19 AM|Yuk Ding|LINK
Have you fixed this issue while I'm not sure whether The Java could work with IIS client certificate mapping authentication.
Oct 01, 2017 09:09 AM|omeganet05|LINK
After doing some research I managed to fix the issue. Although, you configure client certificate in IIS, you still need to enable the negotiation using
netsh http. I wrote this
blog post to clarify the solution. I hope this helps other people as well.
Oct 02, 2017 02:01 AM|mahamr|LINK
What this http.sys setting does is determine whether or not the client certificate is negotiated during the initial TLS handshake, or if it's renegotiated after the TLS connection has been established. Negotiating the client cert on the initial
handshake is not something that is needed or ideal in the vast majority of situations. I'm curious to see if your client reports 100% uptime after this change has been made.