Fog Creek Software
Discussion Board

Bug in Winsock Control

My client has just encountered this (;en-us;319692) bug that Microsoft admits to. It would cost $245 to speak to a support professional at Microsoft to get a fix for this bug. While licence for Visual Studio is not a problem, the KB says that support is chargeable. I do not want to be taxed for this generosity of asking for a way our from a bug that they left into their own software. You guys've come accross this? What's the way out?

sathyaish Chakravarthy
Wednesday, September 24, 2003

I would suggest a VB list is likely to be of more assistance.

Try for instance.


Wednesday, September 24, 2003

Don't we love the old bug & charge business model?  Sorry, but this tactic of M$ really annoys me.

Mike Peterson
Wednesday, September 24, 2003

It's possible that you got 2 free support incidents with your purchase of Visual Studio - check;en-gb;warranty for details.  MSDN also has inicidents included with it.

Also, I've always been of the impression that if it turns out to be a bug, then it's not chargeable - they don't seem to have been charged to our incident count anyway, and that appears to be supported by this:-;en-gb;incident

Wednesday, September 24, 2003

For these sort of things MS don't usually charge.
In fact I've had incidents not be charged when I've had problems with poorly documented windows API problem.

We have 5 incidents a year from MS and so far I think we've used up one and that was me looking for advice on how to get to non-default interfaces on COM objects from VBScript (which they gave) Since you MUST have a Visual studio license to get the fix (either via MSDN or by purchase) you almost certainly have some incidents you can use for this.

Usually I tend to find that as part of the process of compiling enough information to be able to call MS I fix the problem. So far we've only stumped them once with a SQL problem which the documentation suggests should work and in fact doesn't (Again we got the incident back)

In this case whats wrong with flagging your socket session in the close event and then never calling get data as a workaround (sounds like it should work anyway)

Peter Ibbotson
Wednesday, September 24, 2003

Reasonably sure that you can't build with the winsock control unless you already have a license, and the only way you can obtain a license is to own a pro or enterprise edition of visual studio.

Wednesday, September 24, 2003

What the note is explaining is that if you call for the fix, and it turns out that the problem isn't a bug, you'll be charged. But if the problem *is* the bug, then you won't be charged.

a) Please learn a little reading comprehension
b) Once again, can we all turn down the "M$ sucks" rhetoric, at least until all the facts are in and we've read them
c) I'll bet this disclaimer went on the page after the tenth or twentieth call about this KB article that turned out to be a coding error. The caller got charged and threw a fit. So - disclaimer on the page. (Based on the legal theory that every warning is based on an actual lawsuit)


Wednesday, September 24, 2003

I second Philo's opinion.

From the MS page in question:
"NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

In other words, if you call about this bug and ONLY this bug, you don't have to pay.

On the other hand, you could record the fact that the Close event has already fired and simply ignore the DataArrival event.  Then you wouldn't have to bother with calling MS at all.

Wednesday, September 24, 2003

As Craig alluded to, this seems like an easy enough bug to workaround.  Can't you just not call GetData on closed sockets?  This seems better than having to worry about having the right Winsock control installed. 

Wednesday, September 24, 2003

Yeah just check the 'State' property before doing a GetData.  That will tell you if you are connected or not.

I decided not to use dataarrival.  I was worried about not recieving a full message all at once.  Instead I did an endless loop (in seperate from my main app thread) that checks the 'bytesrecieved' property until I have a full message.  Seems to be working well so far.

Wednesday, September 24, 2003

*  Recent Topics

*  Fog Creek Home