Could not load PHP DLL in memory (2024.x but not 2020)

ExeOutput for PHP
1

Until November we were using a production console EXE compiled with the 2020 version of exeoutput, with no problems (in use on Windows 7, 10, 11).

When recent Windows updates broke that version, we noticed on your site that the 2024 version should be used for Windows 11 compatibility, tested 2024.1 and got the error message “Could not load PHP DLL in memory”, saw that this was a known issue with these new Windows updates, and waited for you to release 2024.2 as a fix for the issue.

When 2024.2 came out, we started a general production release with a 2024.2 generated EXE (except for Windows 7 PCs: due to the loss of the required VC++ for Windows 7 in the 2024-generated EXE, we’re now maintaining a parallel production EXE generated with the 2020 compiler).

2024.2 makes a console EXE that works on many PCs where 2024.1 did not.

However, when doing a general update, our 2024.2-built EXE sometimes results in the same type of error message. One PC makes a good example:

Microsoft Windows 10 Pro
10.0.19045 N/A Build 19045
Result:
Exception(2024.2.0): Could not load PHP DLL in memory

On this PC, our previous production EXE (made with the 2020 compiler) works. However, an EXE compiled with 2024.1 does not (!) in the same way.

Since this is an issue with both 2024.x versions (not a new problem introduced in 2024.2) I’m not putting this in the thread for the 2024.2 release, and since this example is on Windows 10 I’m not putting this in the thread for the 2024.1 Windows 11 update incompatibility. So I’m making this as a new thread.

Are there any known issues that would cause this error message (besides what was fixed in 2024.2) on 2024.x that would not have affected 2020?

2

Which version of PHP are you using?
Recent PHP versions require an updated VC++ runtime. Maybe it is outdated on your Windows 10 PC?

3

The 2024.2 EXE uses PHP 7.4, the 2020 EXE uses PHP 7.3.

I was aware that the 2024.x version does not include the VC++ runtime needed for Windows 7, which is why we’re distributing an EXE for Windows 7 users that was built with the 2020 version. Is this also an issue for Windows 10 (that EXEs built with 2024.x don’t include the necessary VC++ runtime)?

We’re also seeing the symptom on some Windows 11 PCs. An example:

Edition Windows 11 Pro
Version 24H2
Installed on ‎12/‎8/‎2024
OS build 26100.2605
Experience Windows Feature Experience Pack 1000.26100.36.0

Exception(2024.2.0): Could not load PHP DLL in memory

The 2020 version EXE is working there (I have not tested the 2024.1 version on that PC).

I had highlighted the Windows 10 example to show that it wasn’t just a Windows 11 issue, but it’s also affecting what look like new installations.

A separate thought, would this specific error message (Could not load PHP DLL in memory) be expected under Windows 10/11 if the cause was that the VC++ runtime was not available? When this condition happens on Windows 7, I see a different error message that explicitly identifies that the problem is the missing VC++ runtime.

(At first I was going to use PHP 7.4 on both the 2020 and 2024.2 versions for consistency, but found I was getting VC++ runtime errors on 2020/7.4 under Windows 7. These went away when I switched to 2020/7.3.)

4

“Could not load PHP DLL in memory” occurs when the PHP main DLL could not be loaded. There could be several reasons such as missing dependencies (the VC++ runtime recent release), OR if there is already another PHP distro running (another WAMP package for instance) OR if an antivirus interferes with loading DLLs. Have you also checked if there is something listed in the Event Viewer?

5

There’s no other PHP running on these PCs, they’re single-purpose dedicated PCs (basic Windows + whatever customer IT installs + our software).

Antivirus is a possibility. Usually it’s known to make antivirus exceptions in case of difficulty, but with focus on the Windows 11 update problems it’s possible that was overlooked. I’ll also ask about Event Viewer information.

Is there any documentation or information about when VC++ needs to be installed on a PC?

The explanatory text under “application output - deployment” in exeoutput says all dependencies are included, and no runtime is required. The 2020 version (but not 2024) also has a checkbox option to exclude the VC++ runtime with the note that, if checked, users may need to install the runtime separately. The way I read this, under default/normal conditions (box not checked) it should not matter whether Windows has VC++ runtimes installed or not (or what versions) because the EXE provides its own VC++ runtime.

I was surprised to find that an EXE from the 2020 version using PHP 7.4 generated a VC++ runtime missing error on my Windows 7 PC. Since I thought all dependencies are included in the EXE, I thought this could never happen.

The 2024 version information was clear that 2024-generated EXEs don’t have the VC++ runtime needed for Windows 7. But I thought that the EXE would include any dependencies needed to run on any Windows 10 or 11 PC.

I’d like to convey to customers what system requirements are needed to run the software. If that includes installing VC++ under some circumstances (besides the clear “2024 on Windows 7” case), I’d like to know what those conditions are … (how to know if it will work, or if an install is required)

6

There is no other dependencies than Visual C++ Runtime. Before we could integrate it into the EXE, but the recent versions are more complex. The runtime installer itself contains different versions.
A solution is to ship the VC++ runtime installer (see in the Redist subfolder of ExeOutput) with your EXE file, or better, create an installer for your app that also runs the VC++ runtime installer with Paquet Builder for instance.
The direct link to the installer is:
https://aka.ms/vs/17/release/vc_redist.x86.exe

7

We tried installing the current VC++ from the Microsoft link on the Windows 10 PC cited above. That did not make the 2024.2-compiled EXE work, and it also broke the 2020-compiled EXE (which had worked there before the install).

To answer your other questions about this PC, there is no antivirus (just normal Windows security with nothing recent in protection history), and there was nothing relevant in the event log.

How could installing the latest VC++ break either EXE? That makes no sense to me, but there has to be some architectural explanation about VC++ runtimes that might give a clue about what’s going on.

We found that reinstalling Intel Driver Support Assistant made it work, but we have no idea why.

Technical support is pressing for starting a manual process of installing or reinstalling Intel Driver Support Assistant on all PCs with the software (a tedious process that will take hundreds of hours). That seems like a strange hack to me, and I don’t feel confident that it’s a universal solution.

If we can’t use this as a standalone EXE, I’d like to say that the VC++ runtime needs to be installed, that sounds sensible to me. But after the results on the Windows 10 PC, that doesn’t look like a solution. There must be something else that needs to be done, but I have no idea what it might be. I’d like to understand this better before approving a path forward with our software.

I realize “it didn’t work, we don’t know why” is not a terribly useful description of a problem. If there’s anything we can test to better characterize the situation, I’d be happy to gather information that would help for understanding.

8

Yes, the architecture behind VC++ runtimes has become complex, that’s why we stopped integrating the files into the EXE files. Because PHP 8.4 does not require the same VC++ version as PHP 7.3 for instance.
The latest VC++ runtime installer ensures to install the correct versions.

We can suppose that the IDSA software also comes with VC++ runtime, but a given version. A lot of software comes with their local VC++ runtime files in their installation folders. However, if this folder is added to the environment PATH variable, that could make interferences with the system installed VC++ runtime. Could you check the PATH variable on the computers with the IDSA software?

BTW PHP 7.3 and 7.4 require VC CRT 15 (Visual Studio 2017). The Microsoft Visual C++ Redistributable for Visual Studio 2019 is suitable for all these PHP versions, see » https://visualstudio.microsoft.com/downloads/.
Try to use this installer instead of the latest installer. Before, Microsoft had different VC++ runtime installers for each VC runtime. But last years, they started to release a common installer for all VC runtimes.

Anyway, I’ve added this problem to our TODO list for further research. We’ll study the possibility to integrate the VC++ runtime again, at least for old PHP versions.

9

Before trying an install of a VC++ 2019 version, I’d like to ask another question about runtimes, so I better understand the situation …

Taking a wild guess (not knowing much about the subject) based on your reply – does the latest VC++ runtime support PHP 8.4 but not PHP 7.3? If so, that would explain why there’s no longer a specific VC++ runtime you can package with all EXE files regardless of PHP version, and why installing the latest VC++ broke a PHP 7.3 EXE. If so, what versions of PHP are supported by the latest VC++ runtime? We can change our PHP version to simplify compatibility.

10

From the PHP website:
More recent versions of PHP are built with VS16 or VS17 (Visual Studio 2019 or 2022 compiler respectively) and include improvements in performance and stability.

  • The VS16 and VS17 builds require to have the Visual C++ Redistributable for Visual Studio 2015-2022 x64 or x86 installed

PHP 7.3 and 7.4 were built with VC15.

11

To update where we are (both for your information, and for anyone else reading the thread):

We found an unexpected confounding factor from our tests.

We had a report that on some Windows 7 and 10 PCs currently using a PHP 7.3 EXE compiled with 2020, after installing VC 17, installing VC16 was necessary. Without this step, neither the previously working PHP 7.3 nor the PHP 8.1 compiled with 2024.2 would start. After VC16 was installed, both EXEs would start and run normally. I found this extremely confusing for two reasons:

  1. PHP 8.1 requires VC17 … if that’s already installed, adding VC16 would seem both irrelevant (VC17 is there) and useless (the EXE requires VC16).

  2. Nothing was uninstalled, and if a PHP 7.3 EXE was previously working on the PC with whatever was installed, adding VC 17 should not interfere.

Trying to understand this, I used remote desktop software to watch the process on an affected Windows 7 PC. I noticed that what the person was applying was the x86 version of VC16 (after our normal deployment installed the x64 version of VC17, matching the PC system type which reports as x64).

I uninstalled all VC, and installed only the x86 version of VC17. Both PHP 7.3 and 8.1 worked in this configuration. Therefore, it seems that x86 VC is required on some PCs, even if the system type reports as x64.

To run PHP 8.1 on x64 PCs, x64 VC has been sufficient on all Windows 11 PCs, most but not all Windows 10 PCs, and no Windows 7 PCs.

I inspected our EXEs in a hex editor, and they show as a 32-bit EXEs.

I think earlier you said the choice of x64 or x86 should match the system type, but based on my observations, at least on Windows 7 it seems the choice needs to match the 32-bit EXE (not the 64-bit system type).

Questions:

a) does this mean we should be installing the x86 VC even on x64 PCs?

b) do our observations about x86 vs x64 on different versions of Windows make sense, matching what you would expect to be needed by EXEs generated by exeoutput?

Our current strategy is to install x86 VC on Windows 7 and x64 VC on Windows 11, and manually fix Windows 10 x64 PCs that need the x86 VC.

I’m still confused about item #2 above - why installing VC 17 x64 on a PC with VC 16 x86 (so both versions of VC were in place) made a PHP 7.3 from exeoutput 2020 stop working (unable to start) when it had been working before. Nothing was removed, and if the EXE was reaching for x86 it was still there. Yet somehow the existence of the x64 version of VC17 made the EXE unable to start. I don’t understand that. (It may not be important.)

My prior question (17 days ago) was about whether there is a maximum (not minimum) version of VC needed to run a version of PHP, since due to that observation, the existence of VC 17 made the EXE fail to start. That is, do we need to avoid installing VC 17 on PCs that will be running PHP 7.3?

To give an update about my prior question, current tests indicate that VC 17 is compatible with PHP 7.3. When I install VC 17 x86 on affected PCs, the PHP 7.3 EXE starts and works normally. (But I’m still confused how the PC got into a state where the EXE would not start when installing VC 17 x64.)

It gets even more bizarre. I’ve seen a case where an EXE starts under one filename, but when copied to another filename won’t start (where that filename was previously used to try running an EXE compiled with a later version of PHP incompatible with the installed VC). I suspect there’s some kind of caching by filename about a file going on within Windows that isn’t cleared by replacing the file. If so, that might contribute to some of my puzzling reports, where I thought I was cleanly testing the EXE file in place, but in fact cached incorrect information in Windows was making the test not clean. That hypothesis is highly speculative, I really do not understand this symptom.

12

We found today a first case of a Windows 11 PC where VC++ x64 was not sufficient (produced the cannot load DLL error, EXE compiled with 2024.2 PHP 8.1). Installing VC++ x86 made the EXE load and work correctly. PC is Windows 11 24H2 x64.

This ties back to my previous question. The EXE produced by 2024.2 shows as 32-bit. Should we be installing VC++ x86 on x64 PCs to match the EXE?

Prior guidance was to match the PC (x64 or x86), but on Windows 7 x64 it seems VC++ x64 never works and x86 is mandatory. VC++ x64 usually works on Windows 10 and 11, but not always.

We’re trying to understand how to know which VC++ is required on a PC (based on EXE type - 2024.2 produces 32-bit, PC type - almost always x64, Windows version - Windows 7/10/11).

We’re currently installing x64 on Windows 10/11 since it matches PC type (and that was the guidance), but seeing some Windows 10/11 that require x86 is making me increasingly wondering if we should be installing x86 everywhere (and if x64 is not needed at all).