5.3 agent scripting "Error creating process"
Launch "$(KACE_SYS_DIR)\xxxxx.exe" with params "yyyy zzzzzz"
with Wait for startup checked (wait='true'), and the script running as local system. As long as xxxxx is a valid Windows command line program, and the params yyyy and zzzzzz are correct, this has always worked perfectly. (Most common example:
Launch "$(KACE_SYS_DIR)\cmd.exe" with params "/c some-valid-cmdline")
Now, with KBOX Agent 5.3.53177, every step with this construction fails every time, with "Error creating process" command line ": (1) Incorrect function".
If I turn off the "Wait for startup" checkbox, the step succeeds. But past testing has shown that I really do need to wait for startup most of the time, for the script steps to execute sequentially in the correct order. (It seems to be a timing thing.)
So, is this a bug? Or do I have to edit every one of my dozens of scripts to remove all the "Wait for startup" checks?
If I do that, how can I ensure one script step completes (e.g., Office 2010 setup.exe) before the next step runs (e.g., to copy the Office 2010 setup log file)?
Answers (5)
With many of you out there with large and mature Kscript libraries, and many of you upgrading to the 5.3 agent for Windows, surely I'm not the only person seeing this error!
Comments:
-
No, you are not the only one seeing this error. I have been beating my head against the wall trying to figure this out. However, I will say this ... I'm not seeing this problem with all my scripts. I have one script that is simply shutting down machines that is working fine. The one that broke is the same script with one different switch to reboot machines that stay on all the time. The command prompt opens, but seems to be stuck and doesn't put the parameters in. If I tell it not to wait for startup, the command prompt opens correctly but the parameters are not run. - smkdvr42 12 years ago
A colleague here might have found the cause of this problem. With the new 5.3 KBOX agent for Windows, it looks like any "Launch a program..." step that ends with the system ERRORLEVEL set to anything but 0, causes the script to abort immediately with this "Error creating process: (1) Incorrect function" message. It doesn't matter whether the task's On Failure: is set to Break or Continue.
In other words, the errorlevel returned by programs is no longer ignored, as it was with the 5.1 agent and as it in in CMD.exe batch files. It is always tested, and if found to be non-zero, the script is aborted with that error message.
Can anyone from KACE confirm this? And can you tell us whether this is meant to work this way, or if there's a bug you intend to fix? I really need to be able to put Wait for startup checked (wait='true') back in some of my Kscripts. Sande
That same colleague found an unrelated bug, but one you might encounter in the same context. With the new 5.3 KBOX agent for Windows, it looks like any "Launch a program...cmd.exe /c ..." step that uses an environment variable in the command line after the /c, parses the command line incorrectly under some circumstances. Here the fix is simple: append a bunch of blank characters on to the end of the command line.
For example, this fails:
Launch ``$(KBOX_SYS_DIR)\cmd.exe" with params "/c copy /y "$(KACE_DEPENDENCY_DIR)\abatch.cmd" %SystemRoot%``
But this works:
Launch ``$(KBOX_SYS_DIR)\cmd.exe" with params "/c copy /y "$(KACE_DEPENDENCY_DIR)\abatch.cmd" %SystemRoot% ``
Note that it's only when running cmd.exe and only when the command line has one or more Windows %avariable% environment variables in it; KACE $(KACE_something) variables are okay.
He suspects it's because of the way the 5.3 agent is substituting for the Windows environment variable on the command line, under-running its buffer. I can't imagine why the 5.3 agent is trying to substitute the Windows environment variables; my whole reason for using cmd.exe /c steps is to have Windows substitute those variables. I expect the KBOX agent to substitute the KACE $() variables, but I don't want it to touch the Windows %% environment variables at all. Sande
so that the conversation will remain readable.