This project has moved and is read-only. For the latest updates, please go here.

COMException: "(37,8):LogonType" when changing user

Nov 15, 2012 at 10:42 AM

I am using v1.9.0.23355 of TaskScheduler and v1.9.0.23358 of TaskSchedulerEditor. I'm trying to use the TaskEditDialog to modify a task which I have created previously using the following code;

taskFolder.RegisterTaskDefinition(taskName, td);

I pop up the dialog like this;

TaskEditDialog editorForm = new TaskEditDialog();
editorForm.Editable = true;
editorForm.RegisterTaskOnAccept = true;

I can modify the task OK, but when I try to change the user who runs the task, say from MyDomain\UserA to MyDomain\UserB, then I get a COMException with the message "(37,8):LogonType".

I've tried a few permutations of the calls to RegisterTaskDefinition, such as;

taskFolder.RegisterTaskDefinition(taskName, td, TaskCreation.CreateOrUpdate, username, null, TaskLogonType.ServiceAccount, null);
With this, I can change between SYSTEM and NETWORK SERVICE with no problem. If I try to change to a normal user then I get an error, which I kinda expected.

I also tried this;

taskFolder.RegisterTaskDefinition(taskName, td, TaskCreation.CreateOrUpdate, username, null, TaskLogonType.InteractiveToken, null);

This allowed me to change to SYSTEM, but not back to MyDomain\UserA. Same exception again.

I would appreciate any guidance that anyone can give me on how to correctly use the library, and please let me know if there's any other information I can supply which would be useful.

Nov 15, 2012 at 2:41 PM

Just a bit more information, after registering a task with the first snippet, if I look at the XML property for it I see the following;

	<Principal id="Author">

Nov 15, 2012 at 5:00 PM

OK so I downloaded the source and put a break point in TaskFolder.cs (line 254);


if (v2Folder != null)
	return new Task(this.TaskService, v2Folder.RegisterTaskDefinition(Path, definition.v2Def, (int)createType, UserId, password, LogonType, sddl));



The issue is seemingly stemming from the parameter UserId. When in the editor, I entered a new user to run the task, say, myDomain\jsmith. The field in the editor is populated with the friendly name, e.g. John Smith, and it is this value that ends up being submitted by the editor to the above constructor. The problem is, it should have been the fully qualified username, myDomain\jsmith.

Tracking this back further, the source of the "friendly" username is in NativeMethods;


public static bool SelectAccount(System.Windows.Forms.IWin32Window parent, string targetComputerName, ref string acctName, out bool isGroup, out bool isService)
	CubicOrange.Windows.Forms.ActiveDirectory.DirectoryObjectPickerDialog dlg = new CubicOrange.Windows.Forms.ActiveDirectory.DirectoryObjectPickerDialog();
	dlg.TargetComputer = targetComputerName;
	if (dlg.ShowDialog(parent) == System.Windows.Forms.DialogResult.OK)
		if (dlg.SelectedObject != null)
			acctName = dlg.SelectedObject.Name;
			isGroup = dlg.SelectedObject.SchemaClassName.Equals("Group", StringComparison.OrdinalIgnoreCase);
			isService = NativeMethods.AccountUtils.UserIsServiceAccount(acctName);
			return true;
	isGroup = isService = false;
	return false;


The line acctName = dlg.SelectedObject.Name is where the name is set and eventually makes its way to the RegisterTaskDefinition call.

Now, I am no expert in this area, so apologies if this suggestion is nonsense, but the property dlg.SelectedObject.Upn seems like it might do the trick instead of Name.

I made this change locally and I now seem able to change my users as expected. I haven't gone as far as actually trying to run the tasks yet, but I'll look at that now and report back on whether it was actually successful.


Nov 16, 2012 at 4:02 PM

The COMExeception you are seeing is coming from the fact that you must match the username and the TaskLogonType. If you are choosing SYSTEM or NETWORK SERVICE, you much choose TaskLogonType.ServiceAccount, if you are choosing an interactive user, the InteractiveToken.

Nov 19, 2012 at 8:46 AM

Hi dahall,

Thanks for your reply - that's fair enough, I can work around that constraint. However - I was seeing this problem even when just changing from one normal user to another (so both should have been OK under the InteractiveToken registration).

Like I mentioned in my further research, it seemed to be caused by the wrong data being extracted from the Active Directory object picker control (the Cubic Orange one). Have you had any issues around this yourself?


Nov 19, 2012 at 7:01 PM

Thanks for pushing your point. I found a few bugs in the implementation of TaskPropertiesControl around prompting for and setting the account. The fixes will be in the next release (1.9.1).

Nov 21, 2012 at 5:40 PM

How long do you expect until the next release regarding this issue?


Thank you

Nov 22, 2012 at 12:13 AM

I have posted the code so you can build and use now. I will package the 1.9.1 release after some more testing over the next two weeks.

Nov 29, 2012 at 10:15 AM

Hi dahall,

Thanks for posting the fixed code, and thanks for taking the time to look into this issue. Much appreciated!