DobePhat,

Have you submitted this bug the php.net bug tracker? Or asked any of them what the code 01D0E18C means? As I have googled your problem and found nothing that matches it. I would suggest that you do this first, if they can give you a reason for the access violation code maybe we could pin point the issue easier.

good idea. Done-
will keep u posted.
thanks

was not able to give the debug team enough info, (I lack skills in this sort of testing).

However, Im happy to report that one of our team members went painstakingly through every upgraded file (made easier by checksum of course) and found a few that did not get overwritten. As well as a few that were not granted http access by default but should have.

Then we installed XOOPSCARE module and ran some routines from its user friendly interface. I have a suspicious feeling that something involved with SESSIONS was/is the culprit.

We also changed the Session file to include regenerated id True and then disabled sessions from the site preferences.

Not sure why, but so far things appear to be running smooth again. only time will tell.

If it continues to go well then I would say we need to consider sessions and their impact on and relationship with a live site. I have seen other recent reports that seem to bring up session info as well.

Meanwhile, Wish us luck!