Okay, well, there is only one way to chase this sort of thing down:   put on your sleuthing hat.   We can presume that the software on both sides knows very well how to do SOAP, so it’s gonna turn out to be something stupid.   ;-)   Let’s go find it . . .

1. First, dump exactly what you think your app is sending, and make extremely sure that it is sending it.   Is it a legitimate SOAP payload?   (Yeah?   Well then, prove it.   Don’t assume anything.   Prove everything.)
2. Now to the Microsoft side.   Is there really a connection?   Does the C# app produce any sort of counter or input to indicate that it is actually receiving anything?   Does it, or any library package that it is using, make any entries in the Application Event-Log?   Check that viewer ... Microsoft apps often carry on quite a chat-storm in the event log viewer.
3. Dummy-up a little client in Perl and see if your server actually responds as expected to that.
4. Still stumped?   Try a tool like Wireshark.   See the connection being made, the information being sent, the response coming back.   Note that Wireshark cannot decrypt an SSL connection, but it can do traffic analysis.   You should see that “ping” followed promptly by that “pong,” and both ping-pong balls should be of a believable size.   (A very-short return-ball is probably an error message.   If the TCP/IP stack refuses to successfully send or receive the messages, you should clearly see that, too.)

Resist the temptation to whack yourself on the forehead, when you find the problem.   If you do say "doh!!" (and it is fairly likely that you will, in situations like this), then please do so quietly.   ;-)