Smart questions
Smart answers
Smart people
Join Tek-Tips Forums

Member Login

Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

nickd87 (TechnicalUser) (OP)
5 May 09 19:56

I have a socket application that I have written in VB6. It loads 500 controls in an array and reuses them whenever I need to create a new socket.

The first time I use the control (ie I .Connect and .SendData) the .RemoteHostIP property is set correctly, showing the full IP address. If I then .Close and reuse the control by .Connect, the .RemoteHostIP property invariably is missing the final digit in the last octet of the IP address.

For example, on its second use, it says the .RemoteHostIP is "127.0.0."

My MSWINSCK.OCX version is

What should I do?

tedsmith (Programmer)
6 May 09 9:41
Have you tried Loading the indexed winsocks only when you want to use them and unloading when finished.
That way you get a "new" winsock each time and you only have the winsocks you need created at the same time.
Say for a range of local ports from 1000 to 1500
Load MyWinsock(LocalPortNumber -1000)
Use it
Then Unload MyWinsock(LocalPortNumber -1000) when finished
Associating the local port number with the index makes it easier to keep track of the sockets to use the right one.

nickd87 (TechnicalUser) (OP)
6 May 09 17:28
Thanks Ted.

I have specifically moved away from loading and unloading the controls because I am under the impression there is an unnecessary time penalty in doing so. Can you confirm or deny that?

Is anyone able to reproduce my problem on their machine?  
Helpful Member!  dilettante (MIS)
6 May 09 19:20
There is a cost penalty in destroying and recreating most reusable components and the Winsock control is no exception.  However the amount of this cost may not be significant in many cases.  Prior to around VB6 SP4 there was a memory leak associated with unloading Winsock controls too.

I haven't seen the particular problem described here before.  Can you create a small test case that exhibits this problem and post the code?

I know it sounds unfriendly, but I suspect your problem is elsewhere in your logic.  Something short that has this issue might make it easier for us to help track it down wherever it is coming from.

Version appears to come from the ill-fated Decomber 2008 Security Rollup that nobody should have installed.  It broke a number of the included components in various ways, and most of us are still awaiting a corrected release.  Note that there is no uninstall path for backing it out either!  You have to replace each DLL and OCX by hand.
strongm (MIS)
6 May 09 19:34
>that nobody should have installed

And fortunately some of us didn't ... <phew>
dilettante (MIS)
7 May 09 8:10
I heard a rumor that a fix was being worked on... back around February.  So far I haven't tracked one down though.
tedsmith (Programmer)
7 May 09 8:50
It only takes 0.0004 sec to load one winsock on my pentium3
(Measured by loading 500 in a loop and dividing by 500)

Because you would never be loading more than one at a time it would be insignificant.

You start off by having a fixed Winsock1(0) with an index of zero but you never use it. Only use loaded ones with index greater than zero.

Better still go back to that current when SP6 was released!

Another big advantage is you only need the same one Dataarrival sub for all winsocks. The index received indicates who was sending it. You can then use the same indexed received data routines for different other computers making your overall code much smaller and easier to follow.

dilettante (MIS)
7 May 09 13:07
There is no reason to avoid using the first control in the array, though people often use it as the listener socket.  You can just as easily use another Winsock control as listener and accept connections on any element of a Winsock array.

Six of one, half dozen of another.
tedsmith (Programmer)
7 May 09 22:31
The reason for not using the 0 indexed socket as one of the normal connections is that it cant be unloaded. Therefore you cant re-use the same sub for all sockets in closing and opening without making an exception for 0.

Sue you can use if for something different like listening.
dilettante (MIS)
8 May 09 4:33
That's one more reason not to unload/reload Winsock controls.  Also look at BUG: Winsock Control Leaks Memory When Unloaded though it seems to have finally been fixed by the VB6 SP6 version of the control.
nickd87 (TechnicalUser) (OP)
8 May 09 5:24
Thanks everyone for your replies.

I can confirm I installed the December 2008 Security Rollup ... whoops.

What's the best course of action? Reinstall my machine? Or would it be sufficient to replace the MSWINSCK.OCX file with an older version?

Just to confirm, the following code reproduces the error on my machine (one form with a winsock control on it):


Private Sub Form_Load()

Winsock1.Connect "", 80

Do Until Winsock1.State = sckConnected


Debug.Print "First use, remote host ip: " & Winsock1.RemoteHostIP



Winsock1.Connect "", 80

Do Until Winsock1.State = sckConnected


Debug.Print "Second use, remote host ip: " & Winsock1.RemoteHostIP

End Sub

In the immediate window I get:


First use, remote host ip:
Second use, remote host ip:

I would prefer to not have to rewrite my code to unload/reload controls if possible.

What should I do next?
dilettante (MIS)
8 May 09 13:26
Version here.  The test case above works as expected, showing the entire IP address.

I'm starting to see a pattern to some of the errors in this "security rollup" release.  Lots of the demonstrated problems seem to be "off by 1" sorts of things.  Here they're probably moving 1 too few characters or have misplaced a terminating NUL in a "C string" somewhere within the control's logic.

Very strange that it even works the first time though.

You might get by just replacing the OCX.  Then again Windows File Protection (or Windows Resource Protection) might defeat this depending on your development OS - but I don't think this is a protected file.  You could try doing it in Safe Mode though.
nickd87 (TechnicalUser) (OP)
8 May 09 19:53
I extracted the VB6SP6B updates, found and extracted the .ocx from in there, then replaced it in my System32 directory. I re-registered the DLL and now everything is working correctly!

Thank you!

I shudder to think of all the other dll's and ocx's I've stuffed up by installing that update however... I guess I'll just have to replace them as I come across abnormalities.

dilettante (MIS)
9 May 09 8:34
The most annoying things about that update are that:
  1. Many of the bugs may linger in a program that seems to work... until suddenly your program does something that breaks.
  2. At least some of the problems were reported to Microsoft as early as January but apparently we have no corrected update yet.
  3. The update is marked as quite critical, correcting serious vulnerabilities.
dilettante (MIS)
9 May 09 8:35

MsChart is another component known to be broken in this update.
dilettante (MIS)
14 May 09 13:38
It appears that MS08-070 has been reissued.  Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files now points to an MSI package dated 5/4/2009.

I have not tested it yet myself.  Proceed with caution.
nickd87 (TechnicalUser) (OP)
15 May 09 4:43
Considering my installation is already stuffed, I installed it.

I can confirm it suffers from the same problem described by me earlier in this thread!

The version number of this newer MSWINSCK.OCX is (as opposed to 13).

Stay away from it!!!
dilettante (MIS)
15 May 09 6:56
It may well be that nobody ever reported this problem, so it slipped by yet again even though others were fixed.  Frustrating though.

I swear they're using interns to "support" VB6 these days.
nickd87 (TechnicalUser) (OP)
16 May 09 20:38
How do you let Microsoft know about a bug with their VB6 stuff?
dilettante (MIS)
16 May 09 21:43
That's the $64,000 question.  I see this though:



Customers in the U.S. and Canada can receive technical support from Microsoft Product Support Services at 1-866-PCSAFETY. There is no charge for support calls that are associated with security updates.

International customers can receive support from their local Microsoft subsidiaries. There is no charge for support that is associated with security updates. For more information about how to contact Microsoft for support issues, visit the International Support Web site.
Microsoft Security Bulletin MS08-070 - Critical

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Back To Forum

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close