Bug kills network interface...

[Guest]

I'm working on a fairly large program split into a client and server part
comunicating over tcp/ip. It's using the TcpClient & TcpListener classes,
only using synchronous calls, apart from the connect call that is using the
asynchronous methods to be able to set a timeout. What's beeing sent over the
network are serialized objects (binary). Over to the bug...

Everything is working just fine when running over ethernet, BUT when we
tried the program over wireless we encountered a very strange bug, namely
that it kills the network interface, and then i really mean kills it, and it
does it at both ends at the same time (the bug can come at any time.)
Stopping the application doesn't help. Restarting windows is the only help.
I've tried on ALOT of different machines and setups, my own development
machine seems most prone to invoke the bug.

Operating systems tried:
XP with no service pack
XP with sp1
XP with sp2

..Net Frameworks tried:
v1.1
v1.1 sp1

and on alot of different machines, and wireless hardware.

What could possibly be so bad that some managed code totally kills a network
interface in windows???

Any ideas anyone? I've tried to isolate the bug but it seems very elusive,
for example if I stop writing debug messages to the console it's alot less
likely that the bug surfaces (but it still does spring to life at times). And
why does it only happen if I'm using wireless interfaces?

Any suggestions or ideas would be greatly appreciated.

Cheers!
-Ted

 

[Peter Huang]

Hi Ted,

Have you tried to simplify your code module by module and then line by line
to see if what code line caused the problem?
Or it is hard to guess what may cause the problem.
Also since the problem is not persisted all the time, I strongly
recommended you contact ms PSS directly, so that they will do further and
detailed troubleshooting with you. (e.g. live debugging) which is beyond
newsgroup support.

You may reach MS PSS via the link below.
http://support.microsoft.com

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Peter,

Yes I have tried simplifying it, but the problem is that when I take away
things that don't even have anything to do with the networking the problem
becomes more and more problematic to reproduce. So my main question here was
just if anyone had ever had any problems similar to this, namely that some
managed code can take down the entire network interface, which sounds like a
bug beyond the scope of the code of the program so to say...

 

[Peter Huang]

Hi

If we can not reproduce the problem it will be hard to track what had
happened, as I suggested before, it would better contact MS PSS which will
create a dump file or live debugging on your machine, which is far beyond
newsgroup support's boundary.
Hope this helps.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[[MSFT]]

Hello,

Currently We are find more resource to assist you on this issue and will
update you as soon as possible.

Regards,

Luke

 

[Mike Liu]

Hi Ted,

User-mode socket operations, Win32 or .Net, should not "kill" a network
interface, wireless or Ethernet.

If the application is explicitly touching the wireless interface settings
via API or other methods, it should look into that portion of the logic.
Otherwise, please check if the wireless driver is signed or not.
Regardless, I strongly suggest you to pursue it with the wireless network
driver vendor for further guidance and a potential resolution.


Thanks,
Mike

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Mike,

Actually my wording of "killing" might not be the best, what actually
happens is that the interface is unable to receive or send any packets, but
it's still viewed as active in "Network Connections" in windows. However if I
then disable the interface in windows, and try to re-enable it, windows says
it's unable to connect to the interface.

I had a look at the driver for my development machine, and it is signed
"Microsoft Windows Hardware Compatibility Publisher". However I've tried with
a whole lot of different machines anyway.

I guess I'll have to contact MS PSS, and see if they can help me out.

 

[Mike Liu]

Hi Ted,

When this happens, can you still use the connection, say FTP, IE, etc?

The bottom line is user-mode applcations should not cause the malfunction
of a NIC.

If this is more of an OS issue, MS PSS should be able to help you.
Otherwise, you may still need to engage the NIC vendor for further input.


Thanks,
Mike

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Mike,

No, after this happens I'm unable to use the connection (on both sides,
both server & client) they can't even reply to a ping from any other location.

Cheers,
-Ted

 

[Mike Liu]

Hi Ted,

If you are not touching the NIC configuraiton settings explicitly using
setup API or via the registry, and the socket calls indeed have _caused_
the malfunction of the wireless NIC, this very likely should be a faulty
NIC driver issue.

In which case, I still recommend you to check with the NIC vendor first and
ask them to confirm it. Of course, you may always open an support issue at
any time with MS PSS for offcial clarifications on what you should and can
do next.


Thanks,
Mike

This posting is provided "AS IS" with no warranties, and confers no rights.