BSOD2600
23rd July 2006 08:13 UTC

Problem creating scheduled task
I need to create a scheduled task on Windows 2000/XP/2003, which runs daily, every 5 minutes with a duration of 24hrs.

Since windows 2000 does not have the schtasks.exe tool, I'm forced to use alternative methods. No, I do NOT want to use the AT command, since then it wouldn't visable to the user. I'm trying to use the CreateTask stuff which is found in the System plugin. Seems though when the installer is in the portion of the script were it creates the scheduled task, the whole installer crashes. This is all I get in the eventlog:

The application, , generated an application error The error occurred on 07/23/2006 @ 00:05:47.237 The exception generated was c0000005 at address 01141519 (Store)

I know it has something to do with the system plugin and the scheduled task, but not sure what I'm doing wrong. I can see the scheduled task does get created... but the entire installer crashes, so doesn't do me any good.

Here is what I've got going:

        ;Create scheduled task
        ${If} $OS != 'Windows2000'
            ExecDos::exec /NOUNLOAD /TIMEOUT=2000 '"$SYSDIR\schtasks.exe" /create /RU SYSTEM /SC MINUTE /MO 5 /TN Cacti /TR "php $INSTDIR\inetpub\wwwroot\cacti\poller.php" /ST 01:00:00' "" "$INSTDIR\Inetpub\wwwroot\cacti\log\schtasks.log"
        ${Else}
            MessageBox MB_OK "Creating win2k task"
            push "Cacti"
            push "Invokes the Cacti poller"
            push "php"
            push "$INSTDIR\inetpub\wwwroot\cacti\"
            push "$INSTDIR\inetpub\wwwroot\cacti\poller.php"
            push "*(&l2, &i2 0, &i2 2006, &i2 1, &i2 1, &i2 0, &i2 0, &i2 0, &i2 9, &i2 0, i 1440, i 5, i 0, i 1, &i2 1, i 0, i 0, &i2 0) i.s"
            Call CreateTask
            Pop $0
            MessageBox MB_OK "CreateTask result: $0"
        ${EndIf}

kichik
23rd July 2006 08:35 UTC

It works fine for me when I test it and aside from a stray `&i2 0` at the end, I can't see anything wrong with the code. Try adding some debug messages in CreateTask to see exactly where it crashes.

BSOD2600
23rd July 2006 16:12 UTC

Well it crashes for me somewhere inside of CreateTask.

I've actually copied the CreateTask function from the forum thread where it was implemented. Is there some other way I'm suppose to do use it? If I don't do that, then I get the error

Error: resolving install function "CreateTask" in install section "Cacti" (1)

kichik
23rd July 2006 16:17 UTC

Of course it crashes inside CreateTask, there's nothing special in the code calling it ;) That's why you should try adding debug message into CreateTask.

BSOD2600
23rd July 2006 16:31 UTC

Alright, did that and found the location, when the scheduled task doesn't exist.

#Function CreateTask
     MessageBox MB_OK "debug10"

End:
     ; restore registers and push result
     System::Store "P0 l"
     MessageBox MB_OK "debug20"
FunctionEnd

It crashes right after debug10, so I assume its the system:store line which is the cause.

When the scheduled task already exists, it crashes in a different spot

     ; ITask->SetComment()
     System::Call '$R2->18(w r1)'

kichik
23rd July 2006 18:41 UTC

Hmm... There's error checking for ITaskScheduler->NewWorkItem(). It shouldn't crash if it returns ERROR_FILE_EXISTS.

I still can't see why it would crash when the task doesn't already exist. Does it work with the original TASK_TRIGGER structure from the example?

BSOD2600
23rd July 2006 21:42 UTC

Nope, using the sample code chunk from that nsi file crashes on System::Store "P0 l". Running the installer again, it then crashes on System::Call '$R2->18(w r1)'.

Sounds like brainsucker didn't test this code on Windows 2000.

I'm not setting the SetPluginUnload alwaysoff or SetPluginUnload manual stuff. Would that be causing this problem? Anything special I need to consider since I'm using other plugins too?

kichik
24th July 2006 19:34 UTC

The first crash is caused by the lack of SetPluginUnload. SetPluginUnload alwaysoff tells NSIS to keep plug-ins loaded. When it's used, plug-ins aren't unloaded from memory after the plug-in call line. In this specific case, the first code line in CreateTask saves variables on a new stack. A pointer to that stack is kept in the plug-in's memory. When it's unloaded, because SetPluginUnload alwaysoff isn't used, that pointer is gone. When the plug-in is reloaded in the last line, that pointer points to a new stack that doesn't contain the pushed variables from the first line. When the plug-in tries to pop the variables from this wrong stack, it crashes because they're not there.

The second problem is actually the same problem as the first, because you've placed the message box before the end label.

BSOD2600
25th July 2006 06:28 UTC

Ah, figured it might've been something with those settings. After enabling that, no more crashes. thanks :-).

Does leaving the setting SetPluginUnload alwaysoff make the installer more inefficient / memory intensive?

kichik
25th July 2006 23:32 UTC

I doubt you'll be able to tell the difference in terms of memory usage. However, it might leave plug-ins behind in the temporary folder pending deletion on reboot. You should set it back to manual just before the last plug-in call for it to be unloaded. If you want to contain the effect to CreateTask, have it set to manual just before the Store call.