Just wanted to share a solution to a problem I had for a blissfully short time this evening.

One of our servers is Windows 2003 x64 running PHP 5.2 x64 compiled under VC 2005 (msvcrt80).

With this configuration, the DBG extension would simply not load. Playing with the PHP CLI a bit, I saw first off that the DLL is linked to msvcr90.dll (which is expected for the NuSphere x64 builds, I realize), but naturally I didn't have that runtime on my box since I only needed msvcr80.

I installed the x64 msvcr90.dll, but that alone doesn't do it because of the mismatch in libraries between the PHP EXE and the DBG DLL, and the fact that DLLs always need to have an embedded, not external, manifest in order to link to VC9 (unless the loading EXE already has a manifest, I suppose).

Anyway, I needed to also

- Copy the standard Microsoft.VC90.CRT.manifest to the PHP directory
- Embed the contents of the above manifest into the DBG DLL as a "Type 2 manifest resource" using the lovely XN Resource Editor

That did it -- I was very surprised that I was able to guess/reason this out quickly, since I don't write managed code. Hope this helps someone!

it's safer to use VCR90 php with VCR90 debugger. Taking into account that command line version of VC 2008 is available for free from MS site and its license allows to use it for the cases like yours, I see no reasons why not to use it.

There's no supported 5.2 x64; AFAIK, the highest-quality one was built by independent devs at Fusion X-Lan who use VC8 ("The PHPx64 Project"). There's little point in my trying to duplicate/double-check their work in trying to get the runtime and a bunch of extensions to compile under VC9, since that's, um, far from my area of specialization, and I can't imagine it producing a more stable result than hacking the depends of just the one extension. The huge advantage of the FXLAN binary is that it allowed us to continue using ISAPI on this particular server, which is not ready for the move to FastCGI we are doing elsewhere, but yet the server needed to be end-to-end x64. We are also using VC9 PHP 5.3 x64 via FastCGI, which I don't need to compile myself since it's coming officially from PHP now.

I didn't check myself, but I remember talks in our company about VC9 ABA for NuSphere TechPlatform. Could you please give it a try? It's a free product.

Sounds interesting, but are you saying the TechPlatform has an x64 version? The only one I see ends with -Win32.

ah, no, my bad, it's 32bit, but at least you can grab configure's arguments from the phpinfo
and I know it's not that easy to get all extensions compiled. In 2001 I spent almost a week to get all official stuff compiled. Now there are even more extensions...

OK, thanks for the feedback. If worse came to worst, I would just take out DBG until I can move the server completely into FastCGI. The reason we've stayed with ISAPI now is because of some things we need to do with application pools. DBG gets us the code insight we need to streamline some stuff so we can do away with the extraneous pools and then move to FCGI. One of those circular things.

ABA is a thing to care of when you mix binaries compiled by different compilers. For example with VC8 runtime you can't use FILE returned by VC6 runtime because of extra fields that were introduced in VC8 and therefore aren't initialized by VC6. I'm not sure what potential problems may happen between VC8 and VC9. Maybe still FILE is not compatible and this FILE is for sure passed between php core and its extensions (including DBG of course). From these perspectives, it does not matter if you use FastCGI or ISAPI. BTW ISAPI is not stable by itself. For production servers I'd recommend IIS Fast CGI http://www.iis.net/extensions/FastCGI

Yes, of course, that is why I noted that we are moving to FCGI. But FCGI has its own stability problems that we battle all the time, and this is the most sensitive server. In my direct case, it is no more stable than ISAPI in the user-facing sense, given the flexibility afforded by application pools. We know some easy ways of making it crash, but these need to be triggered using ADSI API and are thus inaccessible to public users. It may also be that the custom x64 binary, for whatever obscure reason, avoids or delays some problems we did experience when running with official PHP 5.2 (win32) binaries in ISAPI mode (and back then we had maybe 25% of current traffic).

ISAPI uses multithreading feature of IIS and therefore may not be stable with some php extensions. It's known that almost all php extension are just wrappers around 3rd party libraries, and some of them are not threadsafe.
Regarding FastCGI crashes, did you try to find out where it crashes? To do it you will need VS debugger and custom build with debug symbols turned on. This would allow you to know what's going on and optimize further steps. For example if it's crashing in ereg, you could switch to pcre and vice versa.

On the other hand, I know many systems based on Linux and FreeBSD where php is running under Apache and they work for YEARS without any single crashes. Load is about 10-20 requests per second, attacked quite frequently, about 4-5 smalls attacks a day. So they are stable.
At least it's a way to think about.

Um, no, I don't think that a full platform migration is "a way to think about." Frankly, it's inappropriate to suggest it at all. Everyone knows it's an option... in some freakish dreamworld where you have no users, no .NET apps to port, and all the time in the world. It's completely invalid for our requirements.

I'm not attaching a debugger to FCGI right now. When I feel like I'm at the point where I can debug FCGI for free, I might as well write my own preprocessor. I have enough else to do, like actually serve pages to people that do what they want and keep doing it. Which I don't get with FCGI right now. P.S. We don't use any extensions other than mysqli.