Pausing thread kills all Net access

G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

I have a multi-threaded application where each child thread owns a socket
and communicates to the net. If I "SuspendThread" these threads while
they're in the midst of a "recv" call, all network access on the PC stops.
If I then "ResumeThread" the threads, network access is restored. When I say
all, I mean all. Streaming audio quites, pings stop working, RD stops
working. IE can no longer connect to web sites.

It doesn't happen to all of my users but, it does happen to some. I can't
reproduce it on my PC but, I'd guess 5% of my users see this. They all seem
to be running XP. Some are SP2 and some are not. Some use third party
firewalls, some do not.

My theory is that I'm suspending a thread when it's in some state where it's
holding a lock that prevents all other TCP access from working on the PC.
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

I had a similar problem when using a low level NDIS driver to capture
and filter packets. When the thread was stopped/paused the network
failed because packets where no longer being read and so the driver
stack filled up and i guess started dropping all new packets.
I not sure this should happen with what you are doing ie. sockets, but
the way for me to solve my problem was to unload the packet capture
driver after stopping the thread.

Quade wrote:

> I have a multi-threaded application where each child thread owns a socket
> and communicates to the net. If I "SuspendThread" these threads while
> they're in the midst of a "recv" call, all network access on the PC stops.
> If I then "ResumeThread" the threads, network access is restored. When I say
> all, I mean all. Streaming audio quites, pings stop working, RD stops
> working. IE can no longer connect to web sites.
>
> It doesn't happen to all of my users but, it does happen to some. I can't
> reproduce it on my PC but, I'd guess 5% of my users see this. They all seem
> to be running XP. Some are SP2 and some are not. Some use third party
> firewalls, some do not.
>
> My theory is that I'm suspending a thread when it's in some state where it's
> holding a lock that prevents all other TCP access from working on the PC.
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Appreciate the input.

It seems to be tied to onboard Ethernet controllers though not all people
with onboard controllers are having problems (I'm not). I'm contemplating
just abandoning the method of pausing and finding some other scheme. This
is a new problem with a pause method I've used at least for the past 5 years
so, I believe it's some change in Windows.

Q



"Peter Piper" <NoEmail@Email.com> wrote in message
news:cn024d$4bf$1@hercules.btinternet.com...
>I had a similar problem when using a low level NDIS driver to capture and
>filter packets. When the thread was stopped/paused the network failed
>because packets where no longer being read and so the driver stack filled
>up and i guess started dropping all new packets.
> I not sure this should happen with what you are doing ie. sockets, but the
> way for me to solve my problem was to unload the packet capture driver
> after stopping the thread.
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

You would have though onboard ethernet would be exactly the same? I
think you have best solution, stop pausing, is it really required? If
not get rid :)

Quade wrote:

> Appreciate the input.
>
> It seems to be tied to onboard Ethernet controllers though not all people
> with onboard controllers are having problems (I'm not). I'm contemplating
> just abandoning the method of pausing and finding some other scheme. This
> is a new problem with a pause method I've used at least for the past 5 years
> so, I believe it's some change in Windows.
>
> Q
>
>
>
> "Peter Piper" <NoEmail@Email.com> wrote in message
> news:cn024d$4bf$1@hercules.btinternet.com...
>
>>I had a similar problem when using a low level NDIS driver to capture and
>>filter packets. When the thread was stopped/paused the network failed
>>because packets where no longer being read and so the driver stack filled
>>up and i guess started dropping all new packets.
>>I not sure this should happen with what you are doing ie. sockets, but the
>>way for me to solve my problem was to unload the packet capture driver
>>after stopping the thread.
>>
>
>
>