go: x/sys/windows/svc : IsWindowsService doesn't work properly inside a windows container

What version of Go are you using (go version)?

$ go version go1.19.2 linux/amd64
x/sys v0.1.0

Does this issue reproduce with the latest release?

Yes

What did you do?

If I use IsWindowsService() inside a container servercore:ltsc2019 it always returns false, nevermind if I launch it as CLI or as service. In windows containers world the service stack is native. It’s not necessarly a “container pattern” but it’s widely used for multiple reasons. So that method should work.

After some tests, the fail reason seems pretty simple. On the host the “Session ID” of the process svchost.exe (for example) is 0, but inside the container, the “Session ID” of a process svchost.exe is 1. The only process with a session ID 0 inside a container are :

Get-Process | where {$_.SessionId -eq 0}

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
      0       0       56          8                 0   0 Idle
     50       3      456       1212       5.20    964   0 smss
   2117       0      156        136      23.61      4   0 System

But good news, the parent process is still “services.exe”.

WmiApSrv is a random service (it’s the native monitoring stack of windows)

Get-Process -Id (Get-CimInstance Win32_Process -Filter "Name = 'WmiApSrv.exe'" | select ParentProcessId).ParentProcessId

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    218      10     3628       7780     175.66    524   1 services

I think, removing the condition parentProcess.SessionID == 0 could be safe and fine… Any windows guru there ?

In the meantime, the older deprecated funtion IsAnInteractiveSession is also buggy in a container, and never detects an interactive session even if you are in a CLI.

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 1
  • Comments: 24 (11 by maintainers)

Commits related to this issue

Most upvoted comments

@alexbrainman I have a very good news. The answer is already done. They decided to just remove the session Id condition (with the probable risk of a wrong result of you name your own exe “services”).

So x/sys should follow the same logic I think.

Original code https://github.com/dotnet/runtime/blob/36bf84fc4a89209f4fdbc1fc201e81afd8be49b0/src/libraries/Microsoft.Extensions.Hosting.WindowsServices/src/WindowsServiceHelpers.cs#L32