Hello Arno,
Well, I will try to use MadExcept but it is hard to reproduce the error, I
coudn´t reproduce it until now, it just happens on production servers used
on my customers
Actually, another interesting fact is that this is already an unhandled
error because windows just logs unhandled errors from a delphi service app,
so, actually the ICS code HandleBackGroundException is not being triggered
because I don´t receive the event OnBgException from the TWSocketServer, it
seems that it is raising this exception outside any exception handlers of
ICS
Éric
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Thursday, March 22, 2007 3:41 PM
Subject: Re: [twsocket] TWSOCKET Access violation at
address7C8224B2inmodule'ntdll.dll'
Éric Fleming Bonilha wrote:
[..]
> Error 3/6/2007 6:37:27 PM Servidor.exe None 0 N/A TECSRV10
>
> This are the exceptions that are being raised on the server when the
> clients
> connects to it,
Try to get a stack trace generated by MadExcept if you cannot otherwise
debug the application. MadExcept only handles unhandled exceptions, so
you need to comment some try-except blocks in WSocket.pas temporarily.
Start with TCustomWSocket.WndProc like below and see if you can get
a nice bug report.
procedure TCustomWSocket.WndProc(var MsgRec: TMessage);
begin
//try
..
//except
//on E:Exception do
//HandleBackGroundException(E);
//end;
end;
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
please, note that the interval between exceptions is 8
> seconds. In this case I have 3 clients trying to connect to the
> server at an
> interval of 8 seconds (This is a behavour of my client software, it
> tries to
> reconnect to the server if it loses the connection at an interval os 8
> seconds)
>
> Any ideas?
>
> Thanks!
> Éric
>
> Do you find this text in OverbyteIcsWSocket.pas?
>
> { FP:26/09/06 Are FD_READ and FD_WRITE really necessary ? Probably
> not ! }
> { Lodewijk Ellen reported a problem with W2K3SP1 triggering an AV in
> }
> { accept. Keeping only FD_ACCEPT and FD_CLOSE solved the problem.
> }
> { Anyway, a listening socket doesn't send nor receive any data so
> those }
> { notification are useless.
> }
>
> Sounds like the same problem.
>
> --
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
> Éric Fleming Bonilha wrote:
>> Hello all!
>>
>> I´m having a strange problem on my app using ICS 6, I have noticed
>> that my server service raises an exception "Access violation at
>> address 7C8224B2 in module 'ntdll.dll'" but I didn´t got where the
>> problem is happening, analysing the error logs I realised that this
>> error is being raised when a client tries to connect to the server,
>> but this error is just happening on Windows 2003, on XP is OK and the
>> strange is that has no time to occur, it works fine for the most of
>> the time, but sometimes it starts raising those exceptions and my
>> server sofware crashes.
>>
>> I have searched on google for this error and I saw a message that was
>> sent to this list that another user had the same problem as me and it
>> was said that the user has changed some lines of code on ICS and
>> solved it
>>
>> This problem is happening on a lot of mine customers using Windows
>> 2003, on WIndows XP it doesn´t happens
>>
>> Any Ideas
>>
>> Following is the message that Fraçois wrote about the problem:
>>
>> Thanks!!!
>> Éric
>>
>>
>>
>>>
>>> A user reported to me that winsock.accept generate an access
>>> violation at address 7C8224B2 in ntdll.dll when is program runs on a
>>> w2K3 SP1 computer, and only one such computer. He found that
>>> changing the lines:
>>>
>>> FSelectEvent := FD_READ or FD_WRITE or
>>> FD_ACCEPT or FD_CLOSE;
>>> iStatus := WSocket_WSAASyncSelect(FHSocket, Handle,
>>> WM_ASYNCSELECT,
>>> FSelectEvent);
>>>
>>> into:
>>> FSelectEvent := FD_ACCEPT; // Not all events, other wise Access
>>> violation 7C8224B2 in NtDll in Window 2003 sp1.
>>> iStatus := WSocket_WSAASyncSelect(FHSocket, Handle,
>>> WM_ASYNCSELECT,
>>> FSelectEvent);
>>>
>>> solved the problem.
>>> Any one else noticed similar problem ?
>>> Removing FD_READ and FD_WRITE has probably no impact on a listening
>>> socket.
>>> But removing FD_CLOSE probably has (I
