I'm running a couple of console applications using task scheduler. These are applications that perform little backoffice tasks and run as C# console applications.

The applications themselves run perfectly well (i.e. one of them outputs emails at the end of its run and I'm getting these emails) but I'm having issues with getting them to log correctly. They use Log4Net and the configuration appears fine because if I run them manually they produce the logs correctly.

However when I run these under the same user account (confirmed by checking process manager) under task scheduler they don't produce any logs. Its as if they are being starved of the correct privileges (but not throwing exceptions because they execute fine) or task scheduler is somehow sandboxing the disk writes and never letting them touch the actual disk.

I originally tried writing to %AppData% but I read that task scheduler has issues with user variables. So I've now hardcoded the paths to c:\BackOffice\Logs, however this has not changed the unfortunate behaviour at all. D:

Any ideas? This is Microsoft Server 2008 R2 Datacenter running on AWS EC2.

Here is the config for log4net if that helps:

<?xml version="1.0" encoding="utf-8"?>

  <appender name="ConsoleAppender"
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
  <appender name="FileAppender"
    <file value="c:\BackOffice\Logs\LogName_log.txt" />
    <appendToFile value="true" />
    <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />

    <level value="DEBUG" />
    <appender-ref ref="FileAppender" />
    <appender-ref ref="ConsoleAppender" />


This sounds like the UAC issue that I just dealt with -- I found your question while looking for the answer!

In my case, I had to run the scheduled ask with the 'Run with highest privileges' checkbox checked. This worked with the administrator account because with UAC, the administrator token with higher privileges can read / write another users' files (in this case, another administrator's). I tested, and I found that if the task was scheduled to run under the same user as the user who owned the file / directory, that worked even without the 'highest privilege' token.

I haven't determined if all of this applies to non-admin accounts and access, but my assumption would be that since there is no 'higher privilege' token for a non-admin account, it would just fail.

More research, and it looks like the %alluserprofile% directory is where you are supposed to put "this computer" data, as opposed to "per user" data in the %appdata% directory. So perhaps placing it there will solve your problem.

| improve this answer | |

Finally I found my issue. The current working directory was not the app directory so log4net could never find the config file. Luckily there is an optional field within Task Scheduler that allows you to set the starting directory for your task.

| improve this answer | |
  • Now that is freaking buddy! – Coops May 14 '15 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.