runtime: Process.ProcessName throws for services.exe when accessed from a non-admin user
Process.ProcessName
throws when the process is an admin process (like “services.exe”) and the current app is running as a low privilege user. This is a regression from .NET 6, and it breaks Microsoft.Extensions.Hosting.WindowsServices
when running as a non-admin user.
This could possibly be a regression from #59672.
Repro Steps
- Build a console app as below:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>
using System.Diagnostics;
namespace ConsoleApp1
{
internal class Program
{
const int ServicesProcessId = 756;
static void Main(string[] args)
{
var services = Process.GetProcessById(ServicesProcessId);
Console.WriteLine(services.ProcessName);
}
}
}
-
Look in Task Manager for the
services.exe
process and replace the ServiceProcessId with the process ID for your current machine. -
Run the app as you, it prints
services
- Run the app as a non-admin, low privilege user
Unhandled exception. System.InvalidOperationException: Process has exited, so the requested information is not available.
at System.Diagnostics.Process.get_ProcessName()
at ConsoleApp1.Program.Main(String[] args) in C:\Users\eerhardt\source\repos\WindowsService1\ConsoleApp1\Program.cs:line 12
- Change the
TargetFramework
tonet6.0
, and run as the same non-admin, low privilege user:
services
Original Report
I come back to the issue #67093, which is closed. The error still occurs with preview.4 and todays nightly build, but only on Windows Server 2016, not on my local Windows 11 developer machine. The error is:
Application: CloudManagementTool.WorkerService.exe
CoreCLR Version: 7.0.22.27203
.NET Version: 7.0.0-preview.5.22272.3
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitializationException: The type initializer for 'CloudManagementTool.WorkerService.WorkerService' threw an exception.
---> System.InvalidOperationException: Process has exited, so the requested information is not available.
at System.Diagnostics.Process.get_ProcessName()
at Microsoft.Extensions.Hosting.WindowsServices.WindowsServiceHelpers.IsWindowsService()
at ConsoleApp1.Program.<Main>(String[] args) in D:\Test\Program.cs:line 13
A reproducing sample program is quite short, but it only crashes on Windows Server 2016 and when registered and executed as a service. Starting the same code directly from the console works fine.
public class Program
{
public static async Task Main(string[] args)
{
var isService = WindowsServiceHelpers.IsWindowsService();
if (isService)
{
// ...
This issue becomes critical now, because it will make the 7.0 version unsable for windows services on Windows Server 2016.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (17 by maintainers)
Commits related to this issue
- Fix for #70007, fallback to old implementation if optimized way fails (#70073) * Fallback to old implementation if optimized way to query process name fails (#70007) * Add helper tool that reads t... — committed to dotnet/runtime by schuettecarsten 2 years ago
- Fix for #70007, fallback to old implementation if optimized way fails (#70073) * Fallback to old implementation if optimized way to query process name fails (#70007) * Add helper tool that reads t... — committed to ovidiucosteanet/runtime by schuettecarsten 2 years ago
I’ve created a PR with my suggestion for a solution. It will try the new way, and fallback to the old implementation. Please take a look at #70073.
Closed by #70073
Oh this is terrible, I am sorry. The new direct/efficient way, publically documented, requires certain documented access. https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew The old way doesn’t require as much access. Is it acceptable to try the new way, and fallback upon access denied? Or might as well just have one slower but uniform way? Win32 is unfortunately not always what we’d like. 😦
@jaykrell, @eerhardt , @SteveDunn - I just tested, the exception also occurs on Windows 11 and my local developer machine - as long as I use a dedicated local non-admin user. The information about Windows Server maybe came into this because it took some time for me to figure out the local user thing. So it should be possible to debug this on a normal developer machine.