Sdk: Access to the path 'C:\WINDOWS\system32\config\systemprofile' is denied.

[Petermarcu]

@ZackTech commented on Fri Aug 24 2018

Access to the path 'C:\WINDOWS\system32\config\systemprofile' is denied.

I had .net Core 2.0 running on our server. I have just installed .Net Core 2.1 and redeployed my WebApi and on IIS and now I get the following in a Log File:

System.UnauthorizedAccessException: Access to the path 'C:\WINDOWS\system32\config\systemprofile' is denied.
at System.IO.FileSystem.CreateDirectory(String fullPath)
at System.IO.Directory.CreateDirectory(String path)
at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateDirectory(String path)
at Microsoft.DotNet.Configurer.FileSentinel.Create()
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()
at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel, IFirstTimeUseNoticeSentinel firstTimeUseNoticeSentinel, IAspNetCertificateSentinel aspNetCertificateSentinel, IFileSentinel toolPathSentinel, Boolean hasSuperUserAccess, DotnetFirstRunConfiguration dotnetFirstRunConfiguration, IEnvironmentProvider environmentProvider)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)

How do I fix this?

---

@ZackTech commented on Fri Aug 24 2018

I gave IIS_IUSRS Read/Write access to: 'C:\WINDOWS\system32\config\systemprofile'
now in the log file I get:

Welcome to .NET Core!

Learn more about .NET Core: https://aka.ms/dotnet-docs
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs

Telemetry

The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

ASP.NET Core

Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only). For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
No executable found matching command "dotnet-.\Crm.WebApi.dll"

I have run the command 'dotnet dev-certs https --trust' and the certificate is already installed.

Everytime I try to get the Web Api to run I get No executable found matching command "dotnet-.\Crm.WebApi.dll"

---

@Petermarcu commented on Tue Sep 04 2018

This looks like the first run experience that write some sentinel files to know whether it has run before. Moving to the CLI repo.

[peterhuene]

Hi @zacktack. It appears your application DLL isn't being found for activation, resulting in dotnet executing the "first run experience" before searching for an executable with a dotnet- prefix to treat as a built-in command. Unfortunately, your IIS worker process is running under a service account that has no access to write profile data, which is what the "first run experience" attempts to do, resulting in the exception.

Would you mind pasting the aspNetCore elements of your published web.config? I'd also recommend using exec .\Crm.WebApi.dll as the arguments to the dotnet command, because if it fails to find it, the "first run experience" will not run and a more helpful message of The application to execute does not exist: 'Crm.WebApi.dll' would be printed instead.

[ZackTech]

I had another issue related to loading MEF files which required me to remove the dot in several dll files names before they would load correctly. I looked at the Web.config and realised that I had altered the name of the Crm.Web.dll. So I then sorted that, provided IIS_IUSRS Read/Write access to: 'C:\WINDOWS\system32\config\systemprofile' and full access to folder further down (can't remember which one it was) and now the application has started running correctly.

What concerns me that these problems that never existed before, now seem to exist, and I am not really sure why. I have had at least three problems all hit at the same time which is NOT good.

[peterhuene]

Hi @ZackTech,

Provided the application DLL can be found, dotnet itself should no longer be writing any files to C:\WINDOWS\system32\config\systemprofile, so the permissions should not be necessary. Additionally, using dotnet exec <dll> instead of dotnet <dll> will prevent the exception from happening again if the DLL can't be found (and provide the better error message too).

I'm sorry to hear your upgrade to 2.1 did not go as smoothly as expected. Since it sounds like the root cause of this problem has been addressed, I'm going to close this issue for now. Please re-open it if there's anything else related to this issue I can help you with. Thank you!

[disalvjn]

I'm now getting this issue after a 2.1 to 2.2 upgrade, having never gotten it with 2.1. My web.config is:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!--
    Configure your application settings in appsettings.json. Learn more at https://go.microsoft.com/fwlink/?LinkId=786380
  -->
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\myApp.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>
<!--ProjectGuid: C5BDB0C2-8F51-4EE7-B848-6549B69C44F8-->

[livarcocc]

I don't think this thread or this repo are the best places for your comment above @disalvjn. Maybe try aspnet's repo.

[nefcanto]

I also got this error out of the blue. Everything was working and I had no upgrade or whatsoever. And suddenly this appeared.

[willpower18]

I had this error trying to host a .Net Core 3.1 application on IIS 10, I changed the web.config file, which was like this before:

<aspNetCore processPath="dotnet" arguments=".\myapp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />

has been changed to:

<aspNetCore processPath=".\myapp.exe" arguments="" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />

and it worked correctly.