guidox / PC
Read events **7031**, **7034** and **7009**, check the recovery actions with **sc qfailure**, and look for a dump in the service's own folder before you change anything.
**7031** names a service that terminated unexpectedly, **7034** a service that stopped with an error count, and **7009** a timeout. The count in 7034 is the fastest way to see the loop.
Get-WinEvent -FilterHashtable @{LogName='System';Id=7031,7034,7000,7009} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-List
Get-Service -Name 'svcapp' | Select-Object Name,Status,StartType**sc qfailure** shows what Windows does after a failure. A service set to restart after one minute produces exactly the loop you see.
sc.exe qfailure svcapp
sc.exe qc svcapp
Get-CimInstance Win32_Service -Filter "Name='svcapp'" | Select-Object State,StartMode,ExitCode,ServiceSpecificExitCode,ProcessIdThe Application log usually carries the process exit code one line above the service event. A code like 0xC0000005 is a crash, 0x80070005 a permission problem.
Get-WinEvent -LogName Application -MaxEvents 100 | Where-Object { $_.Message -match 'svcapp' } | Select-Object TimeCreated,ProviderName,Id,Message -First 5
Get-WinEvent -FilterHashtable @{LogName='Application';Id=1000,1026} -MaxEvents 5 | Select-Object TimeCreated,MessageA crashing service can write a WER report or a dump. The path is in the WER key or next to the executable, and it names the faulting module directly.
Get-ChildItem "$env:LOCALAPPDATA\CrashDumps" -ErrorAction SilentlyContinue | Select-Object Name,Length,LastWriteTime
Get-ChildItem "$env:ProgramData\Microsoft\Windows\WER\ReportArchive" -ErrorAction SilentlyContinue | Select-Object -First 5 Name,LastWriteTime
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps' -ErrorAction SilentlyContinue | Select-Object DumpFolder,DumpTypeA service that only fails as a service is often a working directory or session problem. Running it in the foreground shows the error message the event log omits.
sc.exe stop svcapp
Get-CimInstance Win32_Service -Filter "Name='svcapp'" | Select-Object PathName
# run the binary in a console as the service account
runas /user:PC01\svc-app "cmd /k C:\Program Files\App\app.exe --console"Correct the cause, reset the failure counter, and watch for ten minutes. A service that stops once and stays running is fixed; one that restarts again is not.
sc.exe failure svcapp reset= 86400 actions= restart/60000/restart/60000/none/0
Restart-Service svcapp
Start-Sleep -Seconds 600
Get-Service svcapp | Select-Object Status
Get-WinEvent -FilterHashtable @{LogName='System';Id=7031,7034} -MaxEvents 3 | Select-Object TimeCreated,IdThe service is not configured to log to the System log. Check the Application log and the service's own log file.
The process ended cleanly, which means it decided to stop. Look for a configuration error or a license check in its own log.
That points at the service account's environment, the working directory or a missing dependency. Compare the two environments.
This is the classic cause. Set the password again with sc config and set it not to expire.
Only while diagnosing. A service that never restarts is worse than one that loops, for most workloads.
Usually System32 for a service. That is why relative paths fail for a service but work in a console.
The WER report and a dump can. The event log alone usually stops at the exit code.
Restore the previous recovery actions with sc.exe failure, and remove any console test you added. The service's own configuration is unchanged.
Free · no account needed · tracks your progress