  ### Store a service's files in a suitable location on disk  Specify an absolute path with <xref:Microsoft.Extensions.Configuration.FileConfigurationExtensions.SetBasePath*> when using an <xref:Microsoft.Extensions.Configuration.IConfigurationBuilder> to the folder containing the files.  ## Troubleshoot  To troubleshoot a Windows Service app, see <xref:test/troubleshoot>.  ### Common errors  * An old or pre-release version of PowerShell is in use. * The registered service doesn't use the app's **published** output from the [dotnet publish](/dotnet/core/tools/dotnet-publish) command. Output of the [dotnet build](/dotnet/core/tools/dotnet-build) command isn't supported for app deployment. Published assets are found in either of the following folders depending on the deployment type:   * *bin/Release/{TARGET FRAMEWORK}/publish* (FDD)   * *bin/Release/{TARGET FRAMEWORK}/{RUNTIME IDENTIFIER}/publish* (SCD) * The service isn't in the RUNNING state. * The paths to resources that the app uses (for example, certificates) are incorrect. The base path of a Windows Service is *c:\\Windows\\System00*. * The user doesn't have *Log on as a service* rights. * The user's password is expired or incorrectly passed when executing the `New-Service` PowerShell command. * The app requires ASP.NET Core authentication but isn't configured for secure connections (HTTPS). * The request URL port is incorrect or not configured correctly in the app.  ### System and Application Event Logs  Access the System and Application Event Logs:  0. Open the Start menu, search for *Event Viewer*, and select the **Event Viewer** app. 0. In **Event Viewer**, open the **Windows Logs** node. 0. Select **System** to open the System Event Log. Select **Application** to open the Application Event Log. 0. Search for errors associated with the failing app.  ### Run the app at a command prompt  Many startup errors don't produce useful information in the event logs. You can find the cause of some errors by running the app at a command prompt on the hosting system. To log additional detail from the app, lower the [log level](xref:fundamentals/logging/index#log-level) or run the app in the [Development environment](xref:fundamentals/environments).  ### Clear package caches  A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. In some cases, incoherent packages may break an app when performing major upgrades. Most of these issues can be fixed by following these instructions:  0. Delete the *bin* and *obj* folders. 0. Clear the package caches by executing [dotnet nuget locals all --clear](/dotnet/core/tools/dotnet-nuget-locals) from a command shell.     Clearing package caches can also be accomplished with the [nuget.exe](https://www.nuget.org/downloads) tool and executing the command `nuget locals all -clear`. *nuget.exe* isn't a bundled install with the Windows desktop operating system and must be obtained separately from the [NuGet website](https://www.nuget.org/downloads).  0. Restore and rebuild the project. 0. Delete all of the files in the deployment folder on the server prior to redeploying the app.  ### Slow or hanging app  A *crash dump* is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.  #### App crashes or encounters an exception  Obtain and analyze a dump from [Windows Error Reporting (WER)](/windows/desktop/wer/windows-error-reporting):  0. Create a folder to hold crash dump files at `c:\dumps`. 0. Run the [EnableDumps PowerShell script](https://github.com/dotnet/AspNetCore.Docs/blob/master/aspnetcore/host-and-deploy/windows-service/samples/scripts/EnableDumps.ps0) with the application executable name:     ```