Bug #15333 Updated: strndup access violation

ID: 15333 Updated by: tshazli@linuxmail.org Reported By: david@harksystems.com Status: Open Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.2.1 New Comment: To James; I have installed 3 machines with IIS 5 on win2k. They all have the same problem with the access violation If you are using PHP ISAPI AND you are accessing a database. On my m/c, I am accessing MSSQL server using ADODB. I've tried using ODBC or MSSQL server ext. module. They fail much more often than using the ADODB. Your system might be stable because maybe you do not use DB or the load on your system is very low. I also noticed that this happens when more than one process are trying to access the DB at the same time (Might help!). Also if you use the low protection in IIS, It helps but does not prevent the problem (the access violation happens less often). Also, to kill the IIS, you need to do the following; There is a file called (iisreset.exe). Dunno why MS made that file (probably a bug they know about it in IIS and cannot fix it) but this file is executed whenever you try to kill IIS. It is a bug itself. So delete this file from the system folder and from DLLCache folder. But you have to know if you delete this file, and IIS craches, you have to restart IIS manually (Or install some monitoring software that monitors the service and restart it whenever it goes down). Also I noticed that adding the ISAPI to each virtual site filter (not from the properties of the IIS itself but rather from each Virtual website properties) helps reducing the AV. Previous Comments: ------------------------------------------------------------------------ [2002-07-22 16:07:49] jmoore@php.net Although there seems to be a common failure in strndup this is probably due to a buffer overflow somewhere which is being caused to overflow by strndup, I can never get these IIS bugs to repeat on my system, IIS seems about as stable as possible here, could you all give me your EXACT versions of 2k, IIS etc and Ill do my best to look into it, if not please can someone install MS VC6 and debug the process when it crashes (See technet/msdn on howto debug services) and get a stack trace so we can see where this crash is happening. I dont really think this bug is critical as things have never been that great on IIS and although its a hassle for a lot of people a work around would be to use PHP as CGI. Removing Critical status. - James ------------------------------------------------------------------------ [2002-07-16 22:26:29] akierum@yahoo.com To restart IIS try to use "Restart IIS" rather than doind stop start. Worked for me :) ------------------------------------------------------------------------ [2002-07-15 19:12:17] david.vidmar@email.si Did you (developers) try to contact MS? I'm sure they would be of some help with this bug! ------------------------------------------------------------------------ [2002-07-15 09:50:56] agustinchernitsky@hotmail.com Okey, this is an update... Interesting one. Since I really need PHP running in ISAPI (for cookies, performance, etc), I reinstalled this weekend our main development server. I installed the server with Windows 2000 Server and applied Service Pack 2. Before we updated the server with the latests security patches from MS, my server was running SP2 and PHP 4.1.2 with no problems. After the Security Patches, everything went wrong. Now, what happened with a Win2k clean installation, with SP2 and PHP 4.2.1: It didn´t work. Got the same PHP Isapi error as before. Hope it helps. ------------------------------------------------------------------------ [2002-07-08 11:45:17] jtate@php.net I looked for the solution to this bug for more time than I had to spend. Problem A is that debugging under IIS is more than a little bit of a hassle. Problem B is that it seems to be a bogus pointer or corrupted memory that causes the access violation, and I wasn't able to track it down. Patches that fix the problem are very welcome, in the mean time, changing the security model to "low" seems to be a valid workaround. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15333 -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1