Éric Fleming Bonilha wrote: I also searched a little bit, all stack traces I found have these three items on top:
7c82fadf ntdll!ExpInterlockedPopEntrySListFault ntdll!RtlpAllocateFromHeapLookaside+0x13 ntdll!RtlAllocateHeap+0x1dd Most likely (native) RtlAllocateHeap is called by HeapAlloc. However that doesn't tell me very much, sorry. > > Actually, another interesting fact is that this is already an > unhandled > error because windows just logs unhandled errors from a delphi > service app, Isn't there additional information logged in the eventlog? > 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 That's right, so probably MadExcept would not help much, however it's worth the try. I fear that you need to get a call stack to find the error. Though I never used it, many people suggest the Application Verifier from Microsoft (free download). Also check thread synchronization (again and again ;-) -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > Éric > > ----- Original Message ----- > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" <twsocket@elists.org> > 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 have yet to do some testing). >>>> >>>> Any tought ? >>>> >>>> Than >> -- >> To unsubscribe or change your settings for TWSocket mailing list >> please goto http://www.elists.org/mailman/listinfo/twsocket >> Visit our website at http://www.overbyte.be > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
