Unauthrorized Access Exception while editing the task.

Mar 28, 2011 at 1:35 PM


I am facing a problem while editing a scheduled task from my application which uses this wrapper.  This problem occurs only when we log in as a standard user and then create tasks in the following way.


1) Log in as a standard user.

2) Launch my application using admin rights (i.e run as a administrator)

3) Create a schedule using the application.

4) Now, switch the user and log in as an admin (using the same credentials which were used to create the schedule).

5) Try to edit the schedule which was created in step 3.

The application crashes with the following message:

System.Unauthorized Exception: {"Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"}

   at Microsoft.Win32.TaskScheduler.V2Interop.ITaskFolder.RegisterTaskDefinition(String Path, ITaskDefinition pDefinition, Int32 flags, Object UserId, Object password, TaskLogonType LogonType, Object sddl)
   at Microsoft.Win32.TaskScheduler.TaskFolder.RegisterTaskDefinition(String Path, TaskDefinition definition, TaskCreation createType, String UserId, String password, TaskLogonType LogonType, String sddl)
   at Microsoft.Win32.TaskScheduler.TaskFolder.RegisterTaskDefinition(String Path, TaskDefinition definition)
   at SampleApplication.TaskSchedulerOperations.EditTaskInTaskScheduler(TaskDetails objTaskDetails)

The same problem does not exist when we try to edit the same schedule using the Windows Task Scheduler.

Any help is greatly appreciated.


Mar 28, 2011 at 6:17 PM

RegisterTaskDefinition, when called with the 2 parameters as you do, pulls the UserId and LogonType from the TaskDefinition.Principal properties. If you used a password before to register the task, you could run into permission problems. You may wish to try specifying all the parameters to that method to ensure you are getting the right results both the first and second times.

Mar 29, 2011 at 7:01 AM
Edited Mar 29, 2011 at 7:03 AM

Thanks for your reply.

But i do not use password to while creating the schedule either.  We do specify the user id and TaskLogOnType while creating and editing the schedules as follows:


 tskDef.Data = ""
            tskDef.Principal.UserId = String.Concat(Environment.UserDomainName, "\", Environment.UserName)
            tskDef.Principal.LogonType = TaskLogonType.InteractiveToken
            tskDef.RegistrationInfo.Author = "My Application"
            tskDef.RegistrationInfo.Description = ""
            tskDef.RegistrationInfo.Documentation = ""
            tskDef.Settings.DisallowStartIfOnBatteries = True
            tskDef.Settings.Enabled = True
            tskDef.Settings.Hidden = False
            tskDef.Settings.RunOnlyIfIdle = False
            tskDef.Settings.IdleSettings.IdleDuration = TimeSpan.FromMinutes(20)
            tskDef.Settings.IdleSettings.WaitTimeout = TimeSpan.FromMinutes(10)
            tskDef.Settings.IdleSettings.StopOnIdleEnd = False
            tskDef.Settings.IdleSettings.RestartOnIdle = False
            tskDef.Settings.Priority = System.Diagnostics.ProcessPriorityClass.Normal
            tskDef.Settings.RunOnlyIfNetworkAvailable = False
            tskDef.Settings.StopIfGoingOnBatteries = True
            If newVersion Then
                tskDef.Principal.RunLevel = TaskRunLevel.LUA
                tskDef.Settings.AllowDemandStart = True
                tskDef.Settings.AllowHardTerminate = True
                tskDef.Settings.Compatibility = TaskCompatibility.V2
                tskDef.Settings.ExecutionTimeLimit = TimeSpan.Zero
                tskDef.Settings.MultipleInstances = TaskInstancesPolicy.Parallel
                tskDef.Settings.StartWhenAvailable = True
                tskDef.Settings.WakeToRun = False
            End If

Am i missing out on certain properties to be set?

Mar 29, 2011 at 6:13 PM

On the registration you perform after the edit, I think you will need to supply the user and logon type in the method call. On the first registration, you are pulling the data for the non-adminstrator account, but impersonating an admin to get the call done. On second registration, you are using the same username but don't have the impersonation working for you which would lead to a failure. When you edit and re-register through the Windows Task Scheduler, I would assume it will show up with a different principal. I believe that by specifying an account that has permissions to make the change implicitly, you will have success.