Re: !EventConnect Problem



Those are probably part of the June roll-up, which I haven't seen released
yet. The dates indicate that they were created in May and it's quite
possible that they were not yet ready in time for the May roll-up, which was
put out in the second week of June, if I remember right. Usually, you just
want to get the roll-ups month-by-month, rather than trying to track down
the patches for each individual QFE...

Paul T.

"Doug Allender" <doug.allender@xxxxxxxxx> wrote in message
news:CF85F0C5-11F1-458C-BB73-8DA2BB75D344@xxxxxxxxxxxxxxxx
found PLatform builder had not been informing me of QFE's. (seem to
remember
this being notified) Used "ceqfecheck" and found many qfe's not added.
After
these, and a shift to Winsock2 the problem seems to have been fixed.
However
I have 2 QFE's I can't find/download -
QFE070511 and QFE070531 specifically x86 and ARMV4I


--
Snr. Des. Eng.
Northern Hi-Tec


"Paul G. Tobey [eMVP]" wrote:

The fact that it's happening per interaction with the client seems very
strange. If it was happening once a day regardless of the number of
interactions, I could understand that, depending on the response times
of,
say, the DHCP server on the network or something of that sort. I think
that
you're going to have to contact MS and use one of the Platform Builder
support incidents (or buy more, if you've used yours already). A capture
of
the network activity around the time of the failure would probably be
useful
to the support engineer. You'll probably want to know whether the socket
is
set for keep-alive, etc., also. You might also look for connections to
suspending that the device might be doing, etc. And, of course, make
really
sure that it does change frequency with the frequency of interactions
with a
client...

Paul T.

"Doug Allender" <doug.allender@xxxxxxxxx> wrote in message
news:C090DC0C-8D29-40CA-B05D-C781CB4F3D9F@xxxxxxxxxxxxxxxx
We can't seem to find any of the above causing us problems, but for
what
its
worth I'll give you some more info, which may or may not be usefull.

We have our CE unit being polled by a PC to provide data via tcp/ip.
with
a
poll time of 500mS we get a break in communication approx once a day,
this
is
approx 2 minuts and accompanied by

0x83a2d400: ndisMResetCompleteStage2: Internal reset
0x83a2d400: *InsertTCB: SetIdleTimerReset
0x83a2d400: InsertTCB: setting fTCBTimerOn to 0
0x83a2d400: *InsertTCB: Restarting TCBTimer
... may get several copies of the TCB Timeouts.

with a poll every 5 seconds the 2 minute brakes were very infrequent
(approx every 8 days), but about once every 2 days we would get a
break
of
approx 20minutes when the event connect messasges are generated over
and
over.

we also see the event connect messages if we try to use the remote
performance tool... so? I'm not sure where I'm going from here. The
socket
server we are using is multi-threaded, however this only seens to have
about
4 threads running to deal with the communications we have going on.

any thoughts
--
Snr. Des. Eng.
Northern Hi-Tec


"Paul G. Tobey [eMVP]" wrote:

The message is printed, best I can read, in the following situations:

1. The socket is not in a listening state. Presumably, this would
occur
if
you bound a socket to the right TCP port number, but didn't call
listen.

2. The address family of the incoming connection doesn't match that of
the
socket bound to the port (and listening).

3. There's a problem with the connection address, sockaddr. I'd have
to
read a bunch more code to see what exactly this is testing for.

4. The incoming connection queue has no room for connections. I
suppose
this might happen if you called listen( 0 ), or if you already had
enough
pending connections to the listening socket that there wasn't room for
another potential client.

Paul T.

"Doug Allender" <doug.allender@xxxxxxxxx> wrote in message
news:2A9573EE-7565-433A-B7F9-43BEDBBF44A7@xxxxxxxxxxxxxxxx
We have a C++ application which uses a lot of TCP connections, and
has
a
bug
we are currently trying to trace. We are using WinCE 4.2 on an arm
platform,
and recieve the following message, repeatedly when our problem
occurs
"!EventConnect: connect not accepted IncConnQ = 0". Has anyone else
seen
this
message, or can anyone point me in the correct direction.


--
Snr. Des. Eng.
Northern Hi-Tec








.



Relevant Pages

  • Re: !EventConnect Problem
    ... the June roll-up is available somewhere, although there's not been the usual ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... the June roll-up is available somewhere, ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... you're going to have to contact MS and use one of the Platform Builder ... You'll probably want to know whether the socket is ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... interactions, I could understand that, depending on the response times of, ... You'll probably want to know whether the socket is ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Asynchronous Socket Server data
    ... The socket server knows what type of data it expects due to the interface ... I can have 1 databuffer only for each datatype to handle multiple connections? ... int bytesRead = handler.EndReceive; ... packetIndex, bytesRead); ...
    (microsoft.public.dotnet.languages.csharp)