Is it safe to ignore the sessionId on a process to detect it as service?

[gillg]

Hi,

On the legacy method WindowsServiceHelpers.IsWindowsService() the logic is based on SessionID == 0 and parent process services.exe.
Using services.exe seems enough, or in the worst case a OR condition on SessionID 0 or 1, but I guess the session is a safety guard in case of a third party software with an exe named services.exe.

The problem is on a windows container, services.exe has a sessionId = 1 and Golang framework steal the logic from this legacy method. So we experience issues with some Golang softwares hosted in docker and compatibles as cli + service. (Otelcollector, Windows exporter, and any other not launched as host process).

Any advice from the Microsoft team ?

Original code here : https://github.com/dotnet/extensions/blob/f4066026ca06984b07e90e61a6390ac38152ba93/src/Hosting/WindowsServices/src/WindowsServiceHelpers.cs#L31
Some details here : golang/go#56335 (comment)

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[gillg]

By the way, other interesting output from a host and container :
Host

> query session
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 services                                    0  Disc
>console           my.username            1  Active

Container

> query session
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
>services                                    1  Disc

Maybe instead of a basic "OR" condition, we should identify the session name "services" instead of testing a session ID.
What de you think ?
What is the good way to retrieve a session name from a session ID ?

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Hi,

On the legacy method WindowsServiceHelpers.IsWindowsService() the logic is based on SessionID == 0 and parent process services.exe.
Using services.exe seems enough, or in the worst case a OR condition on SessionID 0 or 1, but I guess the session is a safety guard in case of a third party software with an exe named services.exe.

The problem is on a windows container, services.exe has a sessionId = 1 and Golang framework steal the logic from this legacy method. So we experience issues with some Golang softwares hosted in docker and compatibles as cli + service. (Otelcollector, Windows exporter, and any other not launched as host process).

Any advice from the Microsoft team ?

Original code here : https://github.com/dotnet/extensions/blob/f4066026ca06984b07e90e61a6390ac38152ba93/src/Hosting/WindowsServices/src/WindowsServiceHelpers.cs#L31
Some details here : golang/go#56335 (comment)

Author:	gillg
Assignees:	-
Labels:	untriaged, area-Extensions-Hosting
Milestone:	-

[jkotas]

This is duplicate of #52416 .

SessionId is no longer checked in the current Microsoft.Extensions.Hosting.WindowsServices sources:

runtime/src/libraries/Microsoft.Extensions.Hosting.WindowsServices/src/WindowsServiceHelpers.cs

Line 32 in 36bf84f

return string.Equals("services", parent.ProcessName, StringComparison.OrdinalIgnoreCase);

[gillg]

Awesome! Thanks a lot for your fast answer. I will circle back with the Golang team.