App does not Run as a service in a Windows Container #52416

Silvenga · 2021-05-06T21:37:42Z

Description

Using the library Microsoft.Extensions.Hosting.WindowsServices and a builder like the following:

public static IHostBuilder CreateHostBuilder(string[] args)
{
    return Host.CreateDefaultBuilder(args)
        .UseWindowsService(options => options.ServiceName = "foobar")
        .ConfigureServices((hostContext, services) =>
        {
            services.AddHostedService<Agent>();
        });
}

When executing as a service in a Windows Container the following can be observed:

System event logs:

# Get-EventLog -LogName Application -Newest 10 | %{ $_.Message }
A timeout was reached (30000 milliseconds) while waiting for the foobar...
A timeout was reached (30000 milliseconds) while waiting for the foobar...
A timeout was reached (30000 milliseconds) while waiting for the foobar...

Application event logs:

# Get-EventLog -LogName Application -Newest 10 | %{ $_.Message }
Windows Management Instrumentation Service subsystems initialized successfully
Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 2

Hosting started

Category: Microsoft.Hosting.Lifetime
EventId: 0

Content root path: C:\Windows\system32

Category: Microsoft.Hosting.Lifetime
EventId: 0

Hosting environment: Production

Category: Microsoft.Hosting.Lifetime
EventId: 0

Application started. Press Ctrl+C to shut down.

Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 1

Hosting starting

Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 2

Hosting started

Category: Microsoft.Hosting.Lifetime
EventId: 0

Content root path: C:\Windows\system32

Category: Microsoft.Hosting.Lifetime
EventId: 0

Hosting environment: Production

Category: Microsoft.Hosting.Lifetime
EventId: 0

Application started. Press Ctrl+C to shut down.

It appears the the "host" (that the right name?) does not detect it's running as a service. So the app defaults to running as a console app.

Digging deeper, there's a check for "am I a service?" in Microsoft.Extensions.Hosting.WindowsServices.IsWindowsService().

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

Lines 18 to 31 in 01b7e73

    
           public static bool IsWindowsService() 
        
           { 
        
               if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) 
        
               { 
        
                   return false; 
        
               } 
        
               var parent = Internal.Win32.GetParentProcess(); 
        
               if (parent == null) 
        
               { 
        
                   return false; 
        
               } 
        
               return parent.SessionId == 0 && string.Equals("services", parent.ProcessName, StringComparison.OrdinalIgnoreCase); 
        
           }

Looking at what this checks:

Is Windows? Yes.
Is there a parent process? Yes.
Is this process named services? Yes.
Is this process executing from session 0? No?!?

# pslist.exe -accepteula -t

Name                             Pid Pri Thd  Hnd      VM      WS    Priv
Idle                               0   0   2    0       8       8      60
  System                           4   8  88 3565    3696     144     160
wininit                          276  13   3  167 4194303    7276    1640
  services                       316   9   5  225 4194303    6832    2348
    foobar                       2908   8  10  241 4194303   25380   12688

# Get-Process -id 316 | select name,SessionId

Name     SessionId
----     ---------
services         1

Apparently services doesn't have to run under session 0?

Other information

While "why are running an app in a Windows Container as a Windows Service? Don't do that." would be a completely valid answer.... We are using Windows Containers to provide short lived sandboxes for integration tests - in this case - testing a Wix installer, installing a .NET 5 based Windows Service (self-contained mode). It would be nice if we could continue doing so with .NET 5.

We were historically using TopShelf under .NET Framework, but we migrated to .NET 5. TopShelf does not perform this session 0 check, only the services name check: https://github.com/Topshelf/Topshelf/blob/03bde8963da8c057ffc6df07ef9600ffdf6047c1/src/Topshelf/Runtime/DotNetCore/DotNetCoreHostEnvironment.cs#L57-L80

Therefore, I propose removing that session id check going forward.

The text was updated successfully, but these errors were encountered:

ghost · 2021-05-06T21:37:48Z

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

Using the library Microsoft.Extensions.Hosting.WindowsServices and a builder like the following:

public static IHostBuilder CreateHostBuilder(string[] args)
{
    return Host.CreateDefaultBuilder(args)
        .UseWindowsService(options => options.ServiceName = "foobar")
        .ConfigureServices((hostContext, services) =>
        {
            services.AddHostedService<Agent>();
        });
}

When executing as a service in a Windows Container the following can be observed:

System event logs:

# Get-EventLog -LogName Application -Newest 10 | %{ $_.Message }
A timeout was reached (30000 milliseconds) while waiting for the foobar...
A timeout was reached (30000 milliseconds) while waiting for the foobar...
A timeout was reached (30000 milliseconds) while waiting for the foobar...

Application event logs:

# Get-EventLog -LogName Application -Newest 10 | %{ $_.Message }
Windows Management Instrumentation Service subsystems initialized successfully
Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 2

Hosting started

Category: Microsoft.Hosting.Lifetime
EventId: 0

Content root path: C:\Windows\system32

Category: Microsoft.Hosting.Lifetime
EventId: 0

Hosting environment: Production

Category: Microsoft.Hosting.Lifetime
EventId: 0

Application started. Press Ctrl+C to shut down.

Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 1

Hosting starting

Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 2

Hosting started

Category: Microsoft.Hosting.Lifetime
EventId: 0

Content root path: C:\Windows\system32

Category: Microsoft.Hosting.Lifetime
EventId: 0

Hosting environment: Production

Category: Microsoft.Hosting.Lifetime
EventId: 0

Application started. Press Ctrl+C to shut down.

It appears the the "host" (that the right name?) does not detect it's running as a service. So the app defaults to running as a console app.

Digging deeper, there's a check for "am I a service?" in Microsoft.Extensions.Hosting.WindowsServices.IsWindowsService().

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

Lines 18 to 31 in 01b7e73

    
           public static bool IsWindowsService() 
        
           { 
        
               if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) 
        
               { 
        
                   return false; 
        
               } 
        
               var parent = Internal.Win32.GetParentProcess(); 
        
               if (parent == null) 
        
               { 
        
                   return false; 
        
               } 
        
               return parent.SessionId == 0 && string.Equals("services", parent.ProcessName, StringComparison.OrdinalIgnoreCase); 
        
           }

Looking at what this checks:

Is Windows? Yes.
Is there a parent process? Yes.
Is this process named services? Yes.
Is this process executing from session 0? No?!?

# pslist.exe -accepteula -t

Name                             Pid Pri Thd  Hnd      VM      WS    Priv
Idle                               0   0   2    0       8       8      60
  System                           4   8  88 3565    3696     144     160
wininit                          276  13   3  167 4194303    7276    1640
  services                       316   9   5  225 4194303    6832    2348
    foobar                       2908   8  10  241 4194303   25380   12688

# Get-Process -id 316 | select name,SessionId

Name     SessionId
----     ---------
services         1

Apparently services doesn't have to run under session 0?

Other information

While "why are running an app in a Windows Container as a Windows Service? Don't do that." would be a completely valid answer.... We are using Windows Containers to provide short lived sandboxes for integration tests - in this case - testing a Wix installer, installing a .NET 5 based Windows Service (self-contained mode). It would be nice if we could continue doing so with .NET 5.

We were historically using TopShelf under .NET Framework, but we migrated to .NET 5. TopShelf does not perform this session 0 check, only the services name check: https://github.com/Topshelf/Topshelf/blob/03bde8963da8c057ffc6df07ef9600ffdf6047c1/src/Topshelf/Runtime/DotNetCore/DotNetCoreHostEnvironment.cs#L57-L80

Therefore, I propose removing that session id check going forward.

Author:	Silvenga
Assignees:	-
Labels:	`area-Extensions-Hosting`, `untriaged`
Milestone:	-

Silvenga · 2021-05-07T19:07:04Z

If this proposal is acceptable, I would be happy to make a pr. 😸

eerhardt · 2021-07-22T23:08:07Z

Getting help from @GrabYourPitchforks offline, the following approach was recommended for identifying if the current process is hosted as a windows service:

enumerate the list of running services on the machine;
call QueryServiceStatusEx on each service handle; and
compare the service's PID to the current process's PID.

We can accomplish (1) above with calling:

runtime/src/libraries/System.ServiceProcess.ServiceController/src/System/ServiceProcess/ServiceController.cs

Lines 694 to 701 in 14d6532

    
           /// <summary> 
        
           /// Gets the services (not including device-driver services) on the local machine. 
        
           /// </summary> 
        
           /// <returns>Set of service controllers</returns> 
        
           public static ServiceController[] GetServices() 
        
           { 
        
               return GetServices(DefaultMachineName); 
        
           }

Then p/invoke into QueryServiceStatusEx to get the service's PID. Comparing the current PID is straight-forward from there.

Moving to 7.0 and marking as "up for grabs".

Silvenga · 2021-07-22T23:13:46Z

Sounds good! I'll see if I have time to work this in the near future.

Silvenga · 2021-07-26T14:00:55Z

I'm not going to be able to work this any time soon. Needing to install native build sdk's/python, modifying PATH, etc. is a bit heavy for my current setup.

I don't suppose there's a way to work extensions without needing to build the whole runtime?

eerhardt · 2021-07-26T18:52:43Z

I don't suppose there's a way to work extensions without needing to build the whole runtime?

Check out @ViktorHofer's response here:
#43118 (comment)

You can build the src project with:

eerhardt@EERHARDT5  C:\git\runtime2   main ≣                                                               [13:30]
❯ dotnet build .\src\libraries\Microsoft.Extensions.Hosting.WindowsServices\src\

and you can run the test project against .NET Framework with:

eerhardt@EERHARDT5  C:\git\runtime2   main ≣                                                               [13:52]
❯ dotnet test .\src\libraries\Microsoft.Extensions.Hosting.WindowsServices\test\ -f net461

So you can do some development without building the whole runtime.

Silvenga · 2021-07-26T21:45:33Z

Oh, thanks - I didn't think about not building the solution (related to the Directory.Build.props I assume?).

My tooling hates this solution - removing the $(NetCoreAppCurrent) resolves most of the problems, I just have to make sure not to commit that. 😹

…2416

wrzucher · 2021-08-20T06:15:51Z

Getting help from @GrabYourPitchforks offline, the following approach was recommended for identifying if the current process is hosted as a windows service:

enumerate the list of running services on the machine;

call QueryServiceStatusEx on each service handle; and

compare the service's PID to the current process's PID.

We can accomplish (1) above with calling:

runtime/src/libraries/System.ServiceProcess.ServiceController/src/System/ServiceProcess/ServiceController.cs

Lines 694 to 701 in 14d6532

/// <summary>

/// Gets the services (not including device-driver services) on the local machine.

/// </summary>

/// <returns>Set of service controllers</returns>

public static ServiceController[] GetServices()

{

return GetServices(DefaultMachineName);

}

Then p/invoke into QueryServiceStatusEx to get the service's PID. Comparing the current PID is straight-forward from there.

Moving to 7.0 and marking as "up for grabs".

I am trying to fix this issue but unfortunately, the described solution does not work.

QueryServiceStatusEx return 0 for service. I think, this happens because service is not running yet, it has status StartPending (I checked it) on the moment when we call QueryServiceStatusEx.

You could see my code here: wrzucher@e5ade03

So, I don't know how this problem could be fixed.

dmytro-pryvedeniuk · 2021-11-15T08:12:01Z

The reporter proposes to delete session id check. Isn't it enough? Do you think it can cause some side-effects?

ZeroRyogi · 2021-11-17T13:42:05Z

Please review #51269 (comment) as the cause of the issue may not be related only to the SessionId validation.

After doing a little bit of testing it appears that the cause of the issue is not the failed validation of parent.SessionId == 0 but rather, at this point var parent = Internal.Win32.GetParentProcess(); has already exited so the fields of parent are no longer available. So if we remove the SessionId validation, it will still fail at parent.ProcessName:

At this point a work around to avoid the exception when directly executing the .exe would be to doing so from the command line:

runas /user:UserName .\path\to\exe\service.exe

In this case parent would be null, the exe would not execute as windows service (because we are doing it directly) but the exception will be avoided.

So, the deletion of the check may be not enough to solve the issue.

Is it possible that the "service" is not being created and spawned as an actual Windows Service but rather as a stand alone executable which expected behavior is to continue running at infinitum?

jhennessey · 2021-11-23T14:52:28Z

I hit this issue as well and can confirm that getting rid of the parent.SessionId == 0 check fixed it for me.

Removing SessionId check in IsWindowsService(). This check is not correct when the process is being run in a Windows container. The container will get a different SessionId. Fix dotnet#52416

eerhardt · 2021-12-06T19:34:57Z

I've created #62452 to remove the check.

Removing SessionId check in IsWindowsService(). This check is not correct when the process is being run in a Windows container. The container will get a different SessionId. Fix #52416

Removing SessionId check in IsWindowsService(). This check is not correct when the process is being run in a Windows container. The container will get a different SessionId. Fix dotnet#52416

…74188) * App does not Run as a service in a Windows Container (#62452) Removing SessionId check in IsWindowsService(). This check is not correct when the process is being run in a Windows container. The container will get a different SessionId. Fix #52416 * Add 6.0.x servicing changes

dotnet-issue-labeler bot added area-Extensions-Hosting untriaged New issue has not been triaged by the area owner labels May 6, 2021

ghost added this to Untriaged in ML, Extensions, Globalization, etc, POD. May 6, 2021

maryamariyan removed the untriaged New issue has not been triaged by the area owner label May 6, 2021

maryamariyan added this to the 6.0.0 milestone May 6, 2021

ghost moved this from Untriaged to 6.0.0 in ML, Extensions, Globalization, etc, POD. May 6, 2021

maryamariyan added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label May 7, 2021

ghost moved this from 6.0.0 to Untriaged in ML, Extensions, Globalization, etc, POD. May 7, 2021

eerhardt modified the milestones: 6.0.0, 7.0.0 Jul 22, 2021

eerhardt added help wanted [up-for-grabs] Good issue for external contributors and removed needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration labels Jul 22, 2021

eerhardt mentioned this issue Jul 22, 2021

Unable to run .NET 5.0 service as a different user #51269

Closed

maryamariyan moved this from Untriaged to 7.0.0 in ML, Extensions, Globalization, etc, POD. Aug 4, 2021

eerhardt mentioned this issue Aug 10, 2021

UseWindowsService() does not work on docker containers #50020

Closed

wrzucher added a commit to wrzucher/runtime that referenced this issue Aug 20, 2021

Check if current app is WindowsService by finding process id dotnet#5…

e5ade03

…2416

eerhardt mentioned this issue Dec 6, 2021

App does not Run as a service in a Windows Container #62452

Merged

ghost added the in-pr There is an active PR which will close this issue when it is merged label Dec 6, 2021

eerhardt closed this as completed in #62452 Dec 9, 2021

ML, Extensions, Globalization, etc, POD. automation moved this from 7.0.0 to Done Dec 9, 2021

ghost removed the in-pr There is an active PR which will close this issue when it is merged label Dec 9, 2021

dotnet locked as resolved and limited conversation to collaborators Jan 8, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

App does not Run as a service in a Windows Container #52416

App does not Run as a service in a Windows Container #52416

Silvenga commented May 6, 2021

ghost commented May 6, 2021

Description

Other information

Silvenga commented May 7, 2021

eerhardt commented Jul 22, 2021

Silvenga commented Jul 22, 2021

Silvenga commented Jul 26, 2021

eerhardt commented Jul 26, 2021

Silvenga commented Jul 26, 2021

wrzucher commented Aug 20, 2021

dmytro-pryvedeniuk commented Nov 15, 2021

ZeroRyogi commented Nov 17, 2021 •

edited

jhennessey commented Nov 23, 2021 •

edited

eerhardt commented Dec 6, 2021

App does not Run as a service in a Windows Container #52416

App does not Run as a service in a Windows Container #52416

Comments

Silvenga commented May 6, 2021

Description

Other information

ghost commented May 6, 2021

Description

Other information

Silvenga commented May 7, 2021

eerhardt commented Jul 22, 2021

Silvenga commented Jul 22, 2021

Silvenga commented Jul 26, 2021

eerhardt commented Jul 26, 2021

Silvenga commented Jul 26, 2021

wrzucher commented Aug 20, 2021

dmytro-pryvedeniuk commented Nov 15, 2021

ZeroRyogi commented Nov 17, 2021 • edited

jhennessey commented Nov 23, 2021 • edited

eerhardt commented Dec 6, 2021

ZeroRyogi commented Nov 17, 2021 •

edited

jhennessey commented Nov 23, 2021 •

edited