{"id":11334,"date":"2022-09-12T05:56:50","date_gmt":"2022-09-12T12:56:50","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=11334"},"modified":"2022-09-13T22:19:10","modified_gmt":"2022-09-14T05:19:10","slug":"windows-event-logs-problem","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/alwaysup\/windows-event-logs-problem\/","title":{"rendered":"Q&A: Why isn’t AlwaysUp Writing to the Windows Event Logs?"},"content":{"rendered":"
\"Why<\/div>\n
\n  Hello,<\/p>\n

I’m hoping you can help me troubleshoot some issues we are experiencing with AlwaysUp. We are currently using version 12.9.0.46.<\/p>\n

A user reported that something wasn’t working correctly with the application we’re running as a service. Upon investigating the issue, I noticed that AlwaysUp doesn\u2019t appear to be writing any logs to the event viewer as stated on this page<\/a>.<\/p>\n

I thought I was maybe just missing any messages, so I stopped and restarted the service after about 1 minute. However, this also didn’t write anything to the Application Logs in Event Viewer.<\/p>\n

Could you assist me in sorting out the reporting please?<\/p>\n

— Lewis<\/p>\n<\/div>\n

Hi Lewis. Let’s dig into your situation.<\/p>\n

Which account runs your application as a Windows Service?<\/h2>\n

Do you have a user specified on the Logon<\/b> tab in AlwaysUp? That’s the account where your application will run.<\/p>\n

For example, this screenshot shows OneDrive configured to run as a service in the “Mike Jones” account:<\/p>\n

\"OneDrive<\/a><\/div>\n

When we start OneDrive in AlwaysUp, the executable runs as “Mike Jones”:<\/p>\n

\"OneDrive<\/a><\/div>\n

And as Process Explorer<\/a> shows, even AlwaysUpService.exe — the headless application that runs your application as a service in the background — operates as the same user:<\/p>\n

\"AlwaysUpService.exe<\/a><\/div>\n

Note that most Windows Services run in the LocalSystem account<\/a> — a predefined local account used by the Service Control Manager<\/a>. Indeed, AlwaysUp will run your application as LocalSystem unless you override it by providing an alternate account.<\/p>\n

But running in a “regular” user account is often the best choice when installing an application as a service. That’s because most desktop applications are tied to the account where they were installed<\/b>. Starting them in an account where they were not installed (and cannot find settings saved during installation and configuration) usually ends in failure.<\/p>\n

That account must have permission to create event logs<\/h2>\n

As illustrated above, the service that AlwaysUp creates runs entirely in the context of the account specified on the Logon tab.<\/p>\n

In your set up, the account doesn’t appear to have the necessary permissions to write to the event logs. That’s why you’re not seeing any records from AlwaysUp.<\/p>\n

Test the account’s event log permissions with PowerShell<\/h2>\n

You can test this theory by running the following PowerShell command from the user’s account<\/b>:<\/p>\n

\nWrite-EventLog -LogName Application -Source "APPNAME<\/b> (managed by AlwaysUpService)" -EntryType Information -EventID 0 -Message "This event was created while testing with PowerShell. Please ignore."\n<\/div>\n

Please replace APPNAME with the name of your application in AlwaysUp.<\/p>\n

Essentially, the Write-EventLog<\/a> command simulates how AlwaysUp works. If Write-EventLog fails, then AlwaysUp will fail too.<\/p>\n

Here is the result of running the command from the “Mike Jones” account for our OneDrive service. Write-EventLog succeeded:<\/p>\n

\"Test<\/a><\/div>\n

And a new event showed up in the Application log:<\/p>\n

\"The<\/a><\/div>\n

So everything looked good for Mike.<\/p>\n

How to enable event logging from your AlwaysUp service<\/h2>\n

You can fix the permission problem in one of three ways:<\/p>\n

    \n
  1. \n

    Grant the user administrative rights.<\/b> As an admin, they will definitely be able to write to the event logs. This may be your easiest way forward.<\/p>\n<\/li>\n

  2. \n

    Leave the user as a non-admin but grant the account specific rights to the Application event log<\/b>. Depending on where the issue is, you may have to update the registry and perform other administrative surgery. These links offer guidance:<\/p>\n