Is Windows Server 2012 (not 2012 R2) supported ?

[gibfahn]

This is a question for @nodejs/platform-windows

I see in our supported platforms list we note that we support >= Windows 7 / 2008 R2. Does that mean we support 2012 (R0) or just 2012 R2 and up?

We seem to only have 2012R2 in CI:

cc/ @joaocgreis

[joaocgreis]

We support both versions of Windows 2012 (and both versions of Windows 8).

Indeed, we don't have Windows 2012 in CI, only 2012R2. Windows 2012 sits in between two versions that we test (2008R2 and 2012R2) and should be sufficiently close to 2012R2 to be covered by it. It's possible that there are bugs specific to 2012 that don't reproduce on any other version, but it's rather unlikely. This is also the case for Windows 8 and 8.1 (and Windows 7 with 2008R2). This is similar to what we have for Linux, there is a minimum version but we don't test every single kernel release.

Furthermore, Windows 8 market share is below 3%, so our resources are probably better allocated as they are now.

[gibfahn]

Okay, I only ask because we internally have a test that only fails on one machine, and that machine is our only Win 2012 box that isn't 2012R2.

How difficult would it be to spin one up for testing purposes?

[BethGriggs]

To add to @gibfahn's comment, the two test failures we see only on Windows 2012 are on v6.x.
I retested all of these on v6.12.3, but have seen it in previous versions. It would be good if somebody else could test this on a Windows 2012 (not R2) box.

parallel/test-debug-uncaught-execption-async

With the error:

  ...
not ok 217 parallel/test-debug-uncaught-exception-async
  ---
  duration_ms: 0.882
  severity: fail
  stack: |-
    
    assert.js:85
      throw new assert.AssertionError({
      ^
    AssertionError: 7 === 1
        at ChildProcess.result.on (D:\build\jenkins-new\v6tstwin\x86node\node\test\parallel\test-debug-uncaught-exception-async.js:19:10)
        at emitTwo (events.js:106:13)
        at ChildProcess.emit (events.js:191:7)
        at maybeClose (internal/child_process.js:877:16)
        at Socket.<anonymous> (internal/child_process.js:334:11)
        at emitOne (events.js:96:13)
        at Socket.emit (events.js:188:7)
        at Pipe._handle.close [as _onclose] (net.js:498:12)
  ...

I hit a failure roughly 1 in 10 times with this test on Windows 2012.

sequential/test-debug-port-numbers

     3 const common = require('../common');
    debug>< Debugger listening on [::]:10001
    debug>connecting to 127.0.0.1:10001 ... ok
    debug>< Debugger listening on [::]:10003
    debug>connecting to 127.0.0.1:10003 ... ok
    debug>break in D:\build\jenkins-new\v6tstwin\x64node\node\test\sequential\test-debug-port-numbers.js:1
   > 1 'use strict';
     2 
     3 const common = require('../common');
    debug>< Debugger listening on [::]:10000
    debug>connecting to 127.0.0.1:10000 ... ok
    debug>break in D:\build\jenkins-new\v6tstwin\x64node\node\test\sequential\test-debug-port-numbers.js:1
   > 1 'use strict';
     2 
     3 const common = require('../common');
    debug>break in D:\build\jenkins-new\v6tstwin\x64node\node\test\sequential\test-debug-port-numbers.js:1events.js:160
          throw er; // Unhandled 'error' event
          ^
    
    Error: kill EPERM
        at exports._errnoException (util.js:1020:11)
        at ChildProcess.kill (internal/child_process.js:409:26)
        at kill (D:\build\jenkins-new\v6tstwin\x64node\node\test\sequential\test-debug-port-numbers.js:42:18)
        at update (D:\build\jenkins-new\v6tstwin\x64node\node\test\sequential\test-debug-port-numbers.js:37:7)
        at Socket.<anonymous> (D:\build\jenkins-new\v6tstwin\x64node\node\test\sequential\test-debug-port-numbers.js:21:65)
        at emitOne (events.js:101:20)
        at Socket.emit (events.js:188:7)
        at readableAddChunk (_stream_readable.js:176:18)
        at Socket.Readable.push (_stream_readable.js:134:10)
        at Pipe.onread (net.js:547:20)
  ...

This test fails approximately 5 in 10 times on Windows 2012.

[joaocgreis]

I spinned up a test machine with Windows 2012 and tried these tests (current v6.x-staging: ae9af7a).

• I could not get sequential/test-debug-port-numbers to fail.
• parallel/test-debug-uncaught-execption-async fails every time. The assertion error 7 === 1 shown above is for the return code of a child process. If the child process command is run outside the test, it fails with a Error: kill EPERM message similar to the one shown above for sequential/test-debug-port-numbers. The failures are likely related.

Output of the child process command

node.exe test/fixtures/debug-uncaught-async.js
debug> (node:3064) There was an internal error in Node's debugger. Please report this bug.
fhqwhgads
Error: fhqwhgads
    at Immediate.emit (C:\Users\node\Desktop\node\test\fixtures\debug-uncaught-async.js:8:17)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5)
(node:3064) There was an internal error in Node's debugger. Please report this bug.
kill EPERM
Error: kill EPERM
    at exports._errnoException (util.js:1020:11)
    at ChildProcess.kill (internal/child_process.js:409:26)
    at Interface.killChild (_debugger.js:1631:16)
    at process.Interface.process.on (_debugger.js:772:33)
    at emitOne (events.js:101:20)
    at process.emit (events.js:188:7)
    at process.exit (internal/process.js:166:15)
    at process.<anonymous> (_debugger.js:40:13)
    at emitOne (events.js:96:13)
    at process.emit (events.js:188:7)
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: kill EPERM
    at exports._errnoException (util.js:1020:11)
    at ChildProcess.kill (internal/child_process.js:409:26)
    at process.<anonymous> (_debugger.js:39:44)
    at emitOne (events.js:96:13)
    at process.emit (events.js:188:7)
    at process._fatalException (bootstrap_node.js:300:26)

Exactly the same revision and binaries pass on Windows 2008R2 and 2012R2. This might take some time to investigate, should we open a new issue or rename this one?

@gibfahn @BethGriggs do you want access to the machine?

[gibfahn]

@gibfahn @BethGriggs do you want access to the machine?

Yes please (for both of us).

EDIT: For background, @BethGriggs works with me at IBM, I can vouch for her.

[bnoordhuis]

Does this issue need to stay open?

[gibfahn]

Does this issue need to stay open?

I think so, it's a test failure that is specific to a platform we claim to support but don't actually run CI on.

[Trott]

Can this be closed now that #19378 has landed?

[richardlau]

Can this be closed now that #19378 has landed?

Yes, I think it can.