Digit missing from last octet using winsock 1

[nickd87]

Hello

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 6.1.98.13.

What should I do?

Nick

 

[tedsmith]

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]

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?

 

[dilettante]

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 6.1.98.13 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]

>that nobody should have installed

And fortunately some of us didn't ... <phew>

 

[dilettante]

I heard a rumor that a fix was being worked on... back around February. So far I haven't tracked one down though.

 

[tedsmith]

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]

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]

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]

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]

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 "google.com", 80

Do Until Winsock1.State = sckConnected

    DoEvents
    
Loop

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

Winsock1.Close

DoEvents

Winsock1.Connect "google.com", 80

Do Until Winsock1.State = sckConnected


    DoEvents
    
Loop

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

End Sub

In the immediate window I get:

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

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

What should I do next?

 

[dilettante]

Version 6.1.97.82 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]

I extracted the VB6SP6B updates, found mswinsck.cab 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.

Nick

 

[dilettante]

The most annoying things about that update are that:
[ol][li]Many of the bugs may linger in a program that seems to work... until suddenly your program does something that breaks.[/li]
[li]At least some of the problems were reported to Microsoft as early as January but apparently we have no corrected update yet.[/li]
[li]The update is marked as quite critical, correcting serious vulnerabilities.[/li][/ol]

 

[dilettante]

FYI:

MsChart is another component known to be broken in this update.

 

[dilettante]

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]

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 6.1.98.16 (as opposed to 13).

Stay away from it!!!

 

[dilettante]

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]

How do you let Microsoft know about a bug with their VB6 stuff?

 

[dilettante]

That's the $64,000 question. I see this though:

Support

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