I have a Hyper-V VM running Windows Server Core 2019 Standard with docker installed and run the Windows image mcr.microsoft.com/windows/servercore:ltsc2019
(this will run in process
isolation mode). I tried to install my application (in silent mode) on that container with msiexec
but always fail, it got an error when running Custom Action Server, here's the log:
MSI (s) (90:1C) [17:32:36:675]: Created Custom Action Server with PID 648 (0x288).
MSI (s) (90:1C) [17:32:36:769]: CA Server Process has terminated.
Action start 17:32:36: SchedServiceConfig.
MSI (s) (90:20) [17:32:36:817]: Note: 1: 1719
CustomAction SchedServiceConfig returned actual error code 1601 (note this may not be 100% accurate if translation happened inside sandbox)
I tried some other installers (MySQL, PostgreSQL,...), they end up the same error. I noticed that the Custom Action Server always start and terminated immediately. But installers without Custom Action can install successfully (like cmake, git,...).
I tried installing these on Windows container in my real machine (in process
isolation mode), all can install successfully.
After some search, I tried the image stefanscherer/chocolatey:0.10.15
, and it worked. I use docker history
and found out that the recently build Windows image has only one layer like this:
IMAGE CREATED CREATED BY SIZE COMMENT
561b89eac394 4 weeks ago Apply image ltsc2019-amd64 3.7GB
And the image stefanscherer/chocolatey:0.10.15
has 2 bottom layers like this:
IMAGE CREATED CREATED BY SIZE COMMENT
...
<missing> 11 months ago Install update ltsc2019-amd64 1.18GB
<missing> 21 months ago Apply image 1809-RTM-amd64 3.47GB
I tried some images that have 2 layers Apply image 1809-RTM-amd64
and Install update ltsc2019-amd64
(images built from few months ago) and they worked perfectly.
So my question is:
mcr.microsoft.com/windows/servercore:ltsc2019
so it can install MSI with Custom Action? I want to build an Windows image can install my MSI installer.So I finally figured out the reason. The Custom Action Server Process is 32-bit so it's always crashed when running, in powershell
try C:\Windows\SysWOW64\cmd.exe
then check with echo $LASTEXITCODE
will be the same result. This is caused by the new security update on Feb 2020, the mismatch between host and container Windows build makes 32-bit processes silently crashed and leads to this issue.
Reference from Microsoft:
This issue was the result of a security change which required an interface change between user mode and kernel mode. Since process isolated containers share the kernel mode with the container host and the container images, user mode component without the update were both incompatible and unsecured with the new secured kernel interface.
If you have container/host with build version after Feb 2020, just update the other (host/container) to a newer build after Feb 2020