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

COMException connecting to Windows 2012 Task Scheduler remotely

Topics: Errors
Nov 27, 2012 at 7:05 PM
Edited Nov 27, 2012 at 7:25 PM


I am using TaskService class running on Windows server 2008 system to connect remotely to Task Scheduler on another Windows server system. The relevant code snippet follows:

var ts = new TaskService(IP address, userId, domain, password);
foreach (Task task in ts.RootFolder.Tasks)

This works great when the target is Windows 2008, but with Windows server 2012 I get the following COM exception:

"The task XML contains a value which is incorrectly formatted or out of range. (Exception from HRESULT: 0x80041318)"

I examined the Task's Xml property returned above. The only difference I see is that it is <Task version=\"1.4\" for Windows 2012, but <Task version=\"1.3\" or lower when remote system is Windows 2008 or Windows 7.

Is there a way to target Win 2012 Task Scheduler remotely from Windows 2008 system?

Thanks, Vasu

Nov 29, 2012 at 8:59 PM

I don't have two systems to test this on, but I'm curious which line in the code above is throwing the exception? Will you send me the stack information?

Dec 3, 2012 at 11:52 AM

The property accessor task.Definition is throwing the exception:

System.Runtime.InteropServices.COMException (0x80041318): The task XML contains
a value which is incorrectly formatted or out of range. (Exception from HRESULT:
   at Microsoft.Win32.TaskScheduler.V2Interop.IRegisteredTask.get_Definition()
   at Microsoft.Win32.TaskScheduler.Task.get_Definition()

And task.Xml is:

<?xml version=\"1.0\" encoding=\"UTF-16\"?>\r\n<Task version=\"1.4\" xmlns=\"\">\r\n  <RegistrationInfo>\r\n    <Source>$(@%SystemRoot%\\system32\\twinapi.dll,-8000)</Source>\r\n    <Author>$(@%SystemRoot%\\system32\\twinapi.dll,-8001)</Author>\r\n    <Description>$(@%SystemRoot%\\system32\\twinapi.dll,-8002)</Description>\r\n  </RegistrationInfo>\r\n  <Triggers>\r\n    <IdleTrigger>\r\n      <Enabled>true</Enabled>\r\n    </IdleTrigger>\r\n  </Triggers>\r\n  <Principals>\r\n    <Principal id=\"AnyUser\">\r\n      <UserId>S-1-5-21-3496727714-3193957637-3381071595-500</UserId>\r\n      <LogonType>InteractiveToken</LogonType>\r\n      <RunLevel>LeastPrivilege</RunLevel>\r\n    </Principal>\r\n  </Principals>\r\n  <Settings>\r\n    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>\r\n    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>\r\n    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>\r\n    <AllowHardTerminate>false</AllowHardTerminate>\r\n    <StartWhenAvailable>false</StartWhenAvailable>\r\n    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>\r\n    <IdleSettings>\r\n      <Duration>PT0M</Duration>\r\n      <StopOnIdleEnd>false</StopOnIdleEnd>\r\n      <RestartOnIdle>false</RestartOnIdle>\r\n    </IdleSettings>\r\n    <AllowStartOnDemand>true</AllowStartOnDemand>\r\n    <Enabled>false</Enabled>\r\n    <Hidden>false</Hidden>\r\n    <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>\r\n    <RunOnlyIfIdle>true</RunOnlyIfIdle>\r\n    <WakeToRun>false</WakeToRun>\r\n    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>\r\n    <Priority>7</Priority>\r\n  </Settings>\r\n  <Actions Context=\"AnyUser\">\r\n    <ComHandler>\r\n      <ClassId>{2D3F8A1B-6DCD-4ED5-BDBA-A096594B98EF}</ClassId>\r\n      <Data><![CDATA[$(Arg0)]]></Data>\r\n    </ComHandler>\r\n  </Actions>\r\n</Task>"

Mar 4, 2013 at 4:11 PM
I got the same problem, The property task.Definition is throwing the same exception.
I'm trying to get Scheduled Tasks from Windows 2012 and Windows 8, and get the same exception.
Any idea how to fix this ?
I have tried with the latest Release version 1.9.3.

Mar 4, 2013 at 7:35 PM
Edited Mar 4, 2013 at 7:36 PM
I'm trying to setup an environment that will let me test this. Until I can, I would try setting the TaskDefinition's Settings.Compatibility property to TaskCompatibility.V2_1 when registering the task. Unfortunately, this may be a limitation of the underlying COM library from Microsoft.
May 8, 2013 at 4:00 PM
Edited May 8, 2013 at 4:00 PM
Hi dahall,
Thank you for your effort, is there any progress with this issue ?

I think that you are right, I suspect that the issue is caused by the underlying Task Scheduler COM library, I fear that this scenario is not supported.
Can we find some workaround for this limitation ?

Windows 8 is able to talk to Windows 7/2008’s Task Scheduler - just the other way around is not working today.
This is very surprising. my expectation would be that the ITaskService::Connect function negotiates the protocol that is used to talk between Windows 7/2008 and 8 - similar to what SMB does. (E.g. if one endpoint “speaks” Task Scheduler 1.3 and the other 1.4, then they should fall back to version 1.3)

May 9, 2013 at 3:54 PM
Edited May 9, 2013 at 4:03 PM
As I mentioned, I don't have a system to test this on, but I have an idea for someone to try. Instead of trying to get the Definition, will someone try getting the Xml and see if an exception is ever thrown? For example,
var ts = new TaskService(IP address, userId, domain, password);
foreach (Task task in ts.RootFolder.Tasks)
My theory is that the 1.3 library chokes on parsing the 1.4 XML. While Microsoft may not chose to fix this, I may be able to work around it in my code. I'm also curious if there are XML results that have the 1.3 version (or earlier) as then the library could just exclude those it can't understand and work with those it can.
May 22, 2013 at 8:40 AM
I tried the code, i can get the XML, it's not throwing any exceptions and the XML is printed to the console.
I got 2 XML's with 1.4 version in the root folder.
I found some tasks with version 1.3 in sub folders.

Can we try the work around ? i can check if it's works on my Windows 8 and Windows 2012 systems.

Thanks again,
Oct 5, 2013 at 6:37 PM

This library has been great except for a couple of issue. I tried to use TaskCompatibility.V2_1 by setting the RegisterOnAccept to false so I can change the compatibility before registering the task. That worked but introduced a whole new can of worms … the need for validating and getting passwords etc.

Is there a resolution for this issue yet or a way to remove TaskCompatibility.V2_2 from the TaskEditDialog and initialize it to TaskCompatibility.V2_1? If I can do that then I can rely on the RegisterOnAccept being set to true and everything working correctly.