Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: 10093 Winsock error on TIdHTTP post


This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 6 - Last Post: Apr 3, 2018 11:48 AM Last Post By: Cornelia von Sc...
Cornelia von Sc...

Posts: 21
Registered: 4/26/07
10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 27, 2018 2:52 PM
I am using the TIdHTTP control to make XML requests to a URL as well as to Post data to a webpage. Initially the 10093 Winsock error appeared intermittently and we mistakenly thought it was operating system related or caused by excessive
XML activity. We have now found that this is not true. It can be duplicated the error on any machine easily.
Everything works correctly until we print a Crystal Report from our application. Once a report is printed, the next TIdHTTP post command executed generates an exception with the 10093 Winsock error.
We are writing the parameters to the post command to a log and they are intact, not a problem of memory being trashed.
We have tried creating the TIdHTTP only on startup of the app, and destroying it on app close versus creating and destroying it for every TIdHTTP transaction. It makes no difference.
Adding a Waiting period of up to 5 seconds after a print has made no difference either.
I have installed SmartSniff (a socket sniffer) on my machine to watch socket activity. The SmartSniff results show that the TIdHTTP transactions are using the remote port 443. I understand that this is because I am posting to a URL with the "https" prefix.
When printing a Crystal report I see other activity on remote port 443. But the urls appear to be Microsoft sites spying on us such as cy2.vortex.daata.microsoft,com.... I am not sure how to interpret the results? Is it OK for other tasks to share remote port 443?
I was told that the 10093 Winsock error happens because there is an imbalance between the WSAStartup and WSACleanUp calls. The calls are definitely balanced in our app as we are using Indy which is apparently balanced. I have several questions.
a) How can I prove that Printing a Crystal Report is messing up the socket?
b) How can I recover from it programmatically? Shutting down the app works but is not an option.
c) Would using a different port from 443 help? How would I do this?
d) Would it help to place our TIdHTTP calls in a dll? Would threading help?

Any help would be much appreciated.
Cornelia
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: 10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 27, 2018 5:46 PM   in response to: Cornelia von Sc... in response to: Cornelia von Sc...
Cornelia von Schellwitz wrote:

Initially the 10093 Winsock error appeared intermittently and we
mistakenly thought it was operating system related or caused by
excessive XML activity.

No, it is not. 10093 is WSANOTINITIALISED, which means your app has
unbalanced calls to WSAStartup() and WSACleanup(). Indy does call
those functions, but they should be balanced, so there is likely extra
calls to WSACleanup() elsewhere in your app.

It can be duplicated the error on any machine easily.

Then you should be able to debug it very easily. Run your app in the
debugger and put breakpoints on the WSAStartup() and WSACleanup()
functions themselves in ws2_32.dll, and then look at the call stacks
when they are called.

Everything works correctly until we print a Crystal Report from our
application. Once a report is printed, the next TIdHTTP post command
executed generates an exception with the 10093 Winsock error.

Then chances are that Crystal Report has a bug in it that is causing a
premature call to WSACleanup().

We are writing the parameters to the post command to a log and they
are intact, not a problem of memory being trashed.

This is not a memory issue. It is a DLL reference counting issue.

We have tried creating the TIdHTTP only on startup of the app, and
destroying it on app close versus creating and destroying it for every
TIdHTTP transaction. It makes no difference.

No, it wouldn't, since Indy would call WSAStartup() only once, when
TIdHTTP (or any other Indy component) is created for the first time,
and would not call WSACleanup() until the app exits.

Adding a Waiting period of up to 5 seconds after a print has made no
difference either.

It is not a timing issue.

I have installed SmartSniff (a socket sniffer) on my machine to watch
socket activity. The SmartSniff results show that the TIdHTTP
transactions are using the remote port 443. I understand that this is
because I am posting to a URL with the "https" prefix.

Yes, 443 is the HTTPS port.

When printing a Crystal report I see other activity on remote port
443. But the urls appear to be Microsoft sites spying on us such as
cy2.vortex.daata.microsoft,com....

Microsoft is not spying on anything.

Is it OK for other tasks to share remote port 443?

Of course. You could have 1000s of connections to remote port 443, and
they would all work fine, as long as they have different local and
remote IP/Port pairs. It is the combination of all 4 values working
together that uniquely identify a connection.

I was told that the 10093 Winsock error happens because there is an
imbalance between the WSAStartup and WSACleanUp calls.

Yes (probably by me in an earlier discussion).

The calls are definitely balanced in our app as we are using Indy
which is apparently balanced.

Just because Indy's calls are supposed to be balanced does not
guarantee that everything in your app is also balanced.

a) How can I prove that Printing a Crystal Report is messing up the
socket?

Use the debugger.

b) How can I recover from it programmatically?

WSANOTINITIALISED means that either WSAStartup() was never called at
all (which we know is not true, or TIdHTTP would not work at all), or
that Winsock functions are being called after WSACleanup() has been
called as many times as WSAStartup() has been called (which we know
Indy should not be doing). Hence the reasoning that there is likely an
unbalanced call to WSACleanup() somewhere.

You can't really recover from this without introducing undefined
behavior. WSAStartup() and WSACleanup() perform reference counting on
the Winsock library. Once WSACleanup() has been called as many times
as WSAStartup() has been called, Winsock is unloaded. Even if you were
to call WSAStartup() to reload it, Indy has internal pointers to
Winsock function that would have to be reset, and you can't easily do
that.

Shutting down the app works but is not an option.

Sorry, but it is likely required to fix up everything.

c) Would using a different port from 443 help?

No. Besides, the remote server dictates what port you must connect to.
443 is the standard port that most HTTPS servers use. The server admin
would have to choose to use a different port. But that makes no
difference to your issue.

d) Would it help to place our TIdHTTP calls in a dll?

No. A DLL runs in the address space of the loading process, and
libraries are loaded at the process layer, so would effect DLLs as well.

Would threading help?

No. This is not a threading issue.

--
Remy Lebeau (TeamB)

Cornelia von Sc...

Posts: 21
Registered: 4/26/07
10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 28, 2018 6:35 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Hi Remy, thanks for your response.

Then you should be able to debug it very easily. Run your app in the
debugger and put breakpoints on the WSAStartup() and WSACleanup()
functions themselves in ws2_32.dll, and then look at the call stacks
when they are called.

Unfortunately I have no idea how to put breakpoints on an external dll using Delphi.
Can you be more specific? I also have more than one instance of that dll on my machine.
Thanks so much
Cornelia
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: 10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 29, 2018 10:28 AM   in response to: Cornelia von Sc... in response to: Cornelia von Sc...
Cornelia von Schellwitz wrote:

Unfortunately I have no idea how to put breakpoints on an external
dll using Delphi.

One way is to open Delphi's 'Winapi.Winsock' and 'Winapi.Winsock2'
units in the code editor, go to their 'implementation' sections, and
put breakpoints on the 'external' statements for WSAStartup() and
WSACleanup(). That will catch any static calls to those functions that
your app makes via those units, if any.

However, Indy loads Winsock dynamically, not statically, so the above
approach won't catch Indy's calls to WSAStartup() and WSACleanup().
Fortunately, Indy's IdWinsock2 unit does have public pointers for all
the Winsock functions that Indy loads at runtime. You can assign your
own functions to the pointers for WSAStartup() and WSACleanup(), and
then Indy will call your functions first, which can then call the real
Winsock DLL functions. Then you can put breakpoints in your functions,
and that will catch Indy's calls to the functions.

Another option is to load the Winsock DLL at app startup, then use
GetProcAddress() to get the memory addresses of the WSAStartup() and
WSACleanup() in the DLL, and then tell the debugger to go to those
addresses and put breakpoints at them. That will catch every call to
the DLL functions whether they are made statically or dynamically.

--
Remy Lebeau (TeamB)
Cornelia von Sc...

Posts: 21
Registered: 4/26/07
Re: 10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 29, 2018 12:46 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Thanks, Remy,
we figured out how to trace into the ws2_32.dll. The calls to WSAStartup and WSACleanup appear balanced.
Still investigating, will keep you posted
Cornelia
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: 10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 29, 2018 5:12 PM   in response to: Cornelia von Sc... in response to: Cornelia von Sc...
Cornelia von Schellwitz wrote:

Thanks, Remy,
we figured out how to trace into the ws2_32.dll. The calls to
WSAStartup and WSACleanup appear balanced. Still investigating, will
keep you posted Cornelia

WSANOTINITIALISED can only occur when WSAStartup() is not called at
all, or WSACleanup() has been called too many times. Are you sure
that is the error you are getting?

--
Remy Lebeau (TeamB)
Cornelia von Sc...

Posts: 21
Registered: 4/26/07
Re: 10093 Winsock error on TIdHTTP post  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 3, 2018 11:48 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
The problem has finally been resolved.
Our software uses novaPDF SDK, a PDF software development kit for developers that want to add PDF creation capabilities to their applications. This products uses Windows socket calls to verify our license, load print profiles etc.
A trace into the ws2_32.dll indicated that the WSAStartp and WSACleanup calls generated by Nova were balanced. These calls were done on the main thread.
However, we also use Crystal Reports .Net for our reporting needs, which reads our database via ODBC. The debugger showed that the ODBC dll was also calling Nova to verify our license but it was doing this on a different thread!.
The WSAStartp and WSACleanup calls on this thread were balanced as well. According to what I have read, in a multithreaded environment, WSACleanup terminates Windows Sockets operations for all threads.
This explains why after printing a Crystal report via ODBC, the next TIdHTTP post failed. When our programmer removed the call to Nova in the ODBC dll, the problem goes away.
Remy Lebeau, thanks so much for your unwavering resolve in helping us resolve an issue that has puzzled us for months. Our development team is very grateful for all the help we have received on the forum.
Cornelia
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02