Fix Event ID 7023 Access is denied Windows Service

Quick answer

For advanced users: run sc.exe sdshow to inspect the service's security descriptor, fix the ACL so the logon account has start/stop rights, and verify the executable's NTFS permissions match the service account.

Event ID 7023 shows up in Event Viewer under Windows Logs > System. It means a service stopped unexpectedly and Windows logged the error message the service returned. When that message is 'Access is denied', it's almost never a random glitch. It's the service account failing to access something—either the service's own executable, a file in its folder, or the service's registry key. I've seen this on a client's print server where a third-party scanner service logged this every night after a Windows update changed the folder ACL.

Here's the thing: people immediately jump to reinstalling the service or the program. That's a waste of time. The real fix is checking two ACLs: the file system and the registry. Both get out of sync after updates or when a service account gets changed.

Step-by-step fix

Identify the service and its logon account. Open Services.msc, find the service that logged event 7023. Right-click > Properties. Note the 'Log on as' account. It might be 'Local System', 'Network Service', or a domain account.
Check the executable's path. In the same Properties window, look at 'Path to executable'—that's in the General tab. It'll be something like C:\Program Files\Vendor\service.exe.
Check NTFS permissions on that folder. Open File Explorer, right-click the folder, Properties > Security. Verify the service account (or the group it belongs to) has at least Read & Execute. If it's a domain account, make sure it's explicitly listed or in a group that's listed.
Check the registry key for the service. Open regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\. Right-click the key > Permissions. The service account needs Read access (and sometimes Full Control if it needs to update its own config). If the account is missing, add it.
Use sc.exe to check the security descriptor. Open Command Prompt as admin. Run sc.exe sdshow . This shows the actual security descriptor for the service control manager. Look for the account's SID and check if it has ST (service start) and RC (service control). If not, rebuild the descriptor with sc.exe sdset—but be careful, that's advanced.

Alternative fixes if the main one fails

If ACLs look fine, the problem might be a corrupted service configuration. Try this:

Run sfc /scannow in an elevated command prompt. Sometimes system files get corrupted and service behavior goes sideways.
Use System Restore to roll back to a point before the error started—if the error appeared after an update, this often works.
Re-register the service DLL if it's a COM component. For example, regsvr32.exe C:\Path\to\file.dll.

One client had a service that kept stopping with 7023. The ACLs were fine, but the service was using a virtual account that had lost its profile. The fix was deleting the service and recreating it with the proper account.

Prevention tip

Don't change service logon accounts arbitrarily. When you do, update the file permissions and registry ACLs immediately. And if you're using a domain account, make sure the service account has 'Log on as a service' right—that's in Local Security Policy. Also, after any Windows feature update, check your third-party services for event 7023 within the first 24 hours. I've caught two issues that way before they caused downtime.