Repository navigation
node.exe 8.7.0 and above does not work in Windows NanoServer container #16603
Description
I have problems running the newer versions of Node 8 in a Windows Nanoserver Container:
-
Version:
8.7.0, 8.8.0, 8.8.1 -
Platform:
Windows -
Subsystem:
Windows Nanoserver Container running in Windows 10 / Windows Server 2016
To reproduce the problem, just download the node.exe of specific versions in a Windows NanoServer container:
PS C:\> docker run -it microsoft/nanoserver powershell
Then inside the container:
PS C:\> $ProgressPreference = 'SilentlyContinue'
PS C:\> iwr -useb https://nodejs.org/dist/v6.11.5/win-x64/node.exe -outfile node-6.11.5.exe
PS C:\> .\node-6.11.5.exe --version
v6.11.5
PS C:\> iwr -useb https://nodejs.org/dist/v8.6.0/win-x64/node.exe -outfile node-8.6.0.exe
PS C:\> .\node-8.6.0.exe --version
v8.6.0
Beginning with Node 8.7.0 this stops working:
PS C:\> iwr -useb https://nodejs.org/dist/v8.7.0/win-x64/node.exe -outfile node-8.7.0.exe
PS C:\> .\node-8.7.0.exe --version
PS C:\>
PS C:\> iwr -useb https://nodejs.org/dist/v8.8.0/win-x64/node.exe -outfile node-8.8.0.exe
PS C:\> .\node-8.8.0.exe --version
PS C:\>
PS C:\> iwr -useb https://nodejs.org/dist/v8.8.1/win-x64/node.exe -outfile node-8.8.1.exe
PS C:\> .\node-8.8.1.exe --version
PS C:\>
Activity
maclover7 commentedon Oct 30, 2017
cc @nodejs/platform-windows
StefanScherer commentedon Oct 30, 2017
Just tested the binaries in Windows Server 1709 images (microsoft/windowsservercore:1709 and microsoft/nanoserver:1709) and all versions 8.7.0, 8.8.0 and 8.8.1 work there.
I have to check my older Windows Server 2016 setup again why it didn't work multiple times.
StefanScherer commentedon Oct 30, 2017
OK, I ran another test on a fresh Window Server 2016 in Azure, tested with several microsoft/nanoserver:10.0.14393.1066 .. microsoft/nanoserver:10.0.14393.1770 (latest) and I can reproduce the problem. Node.exe 8.7.0 ... 8.8.1 don't work in nanoserver images for the LTS channel of Windows Server 2016.
It seems that the newer images for the Semi-annual channel of Windows Server 1709 don't have this problem.
refack commentedon Oct 30, 2017
Ohh boy. This is not going to be fun to debug 🤦♂️
@StefanScherer thank you for the detailed information though 👍 Do you by any chance know where we can find something changelog like between 1770 and 1790?
StefanScherer commentedon Oct 30, 2017
@refack Oh the diff between 10.0.14393.1770 and 10.0.16299.19 = current release of Windows Server 1709 could be a little longer :-) It's not just 20 releases I guess.
refack commentedon Oct 30, 2017
@StefanScherer so it might be easier to figure this out from node's side (although I already have an obvious suspect, the bump in libuv from 1.14.1 to 1.15.0 https://github.com/libuv/libuv/blob/v1.x/ChangeLog)
refack commentedon Oct 30, 2017
P.S. node exits with 0xC0000139 {Entry Point Not Found} so it seems like we started using a new API that doesn't exists in 10.0.14393.1770
refack commentedon Oct 30, 2017
API diff:
new
dropped:
refack commentedon Oct 30, 2017
Most probably
SetWinEventHookStefanScherer commentedon Oct 30, 2017
@refack I also tried older nanoserver:10.0.14393.x images and it's the same there.
But with that list of API changes in Node.js maybe @PatrickLang can have a short look ^^ and give us a hint which might cause problems?
StefanScherer commentedon Oct 31, 2017
Hm, I remember the NanoServer API scan tool. Oh I still have a Docker image of that.
But it doesn't show any errors.
digitalinfinity commentedon Oct 31, 2017
If @refack's assessment is correct, it's likely from libuv/libuv#1408 (since 8.7 upgraded libuv to 1.15.0)- @bzoz can you take a look, we likely need to GetProcAddress of SetWinEventHook rather than statically linking against it if the API is not present Windows NanoServer
16 remaining items
gibfahn commentedon Nov 3, 2017
Reopening because the issue isn't fixed till this patch lands in v8.x and v6.x.
@MylesBorins meant either back out libuv 1.15.0, or float this patch
Not sure if possible, but if libuv could include that patch in a 1.15.1, that would be better than than floating a patch.
I'd rather we float the patch than revert libuv 1.15.0 if possible.
deps: cherry-pick e7f4e9e from upstream libuv
MylesBorins commentedon Nov 3, 2017
cherry-pick in #16724
deps: cherry-pick e7f4e9e from upstream libuv
deps: cherry-pick e7f4e9e from upstream libuv
deps: cherry-pick e7f4e9e from upstream libuv
refack commentedon Nov 5, 2017
Good job everyone 🥇 7 days from report to fix, including a roundtrip through libuv.
StefanScherer commentedon Nov 6, 2017
I want to thank you all involved resolving this so quickly. Can‘t wait for the next release.
tty, win: get SetWinEventHook pointer at startup
deps: cherry-pick e7f4e9e from upstream libuv