What causes "unscheduling error: %v %s" in coreybutler/nvm-windows?

Check whether the task actually still exists: schtasks /query /tn — if it is gone, the error is the known false positive and can be ignored

coreybutler/nvm-windows · warning

unscheduling error: %v %s

Error message

unscheduling error: %v
%s

What it means

UnscheduleTask() executed unschedule.bat (schtasks /delete /tn <name> /f) and the script exited non-zero; the error embeds the process error plus schtasks' combined output. In practice the embedded batch's own `if not errorlevel 0` logic is inverted (errorlevel 0 means success), so this can also fire spuriously even when deletion succeeded.

Source

Thrown at src/upgrade/register.go:207

schtasks /delete /tn "%s" /f > %%output%% 2>&1
if not errorlevel 0 (
	echo failed to remove scheduled task: exit code: %%errorlevel%% >> %%errorlog%%
	type %%output%% >> %%errorlog%%
	exit /b %%errorlevel%%
)
	`, tmp, name)

	err = os.WriteFile(filepath.Join(tmp, "unschedule.bat"), []byte(script), os.ModePerm)
	if err != nil {
		return fmt.Errorf("unscheduling error: %v", err)
	}

	cmd := exec.Command(filepath.Join(tmp, "unschedule.bat"))

	// Capture standard output and standard error
	out, err := cmd.CombinedOutput()
	if err != nil {
		return fmt.Errorf("unscheduling error: %v\n%s", err, out)
	}

	return nil
}

View on GitHub (pinned to 5b18223ca1)

Solutions

Check whether the task actually still exists: schtasks /query /tn <taskname> — if it is gone, the error is the known false positive and can be ignored
Run the nvm operation from an elevated terminal so /delete has rights
Delete manually: schtasks /delete /tn <taskname> /f

Defensive patterns

Strategy: fallback

Try / catch

if err := UnscheduleTask(name); err != nil {
    // verify actual state: the generated batch misreads errorlevel, success can report as failure
    if qerr := exec.Command("schtasks", "/query", "/tn", name).Run(); qerr != nil {
        log.Printf("task %s still present: %v", name, err) // genuine failure
    } else {
        // task is gone; treat error as the known false positive
    }
}

Prevention

After unscheduling, verify with `schtasks /query /tn <name>` instead of trusting the exit error
Be aware the generated batch's `if not errorlevel 0` logic is inverted
Run elevated to avoid genuine access-denied deletions

When it happens

Trigger: schtasks /delete failing: task does not exist (already removed), access denied without elevation, or corrupt task registration. Also fires spuriously because the generated batch treats errorlevel 0 (success) as failure.

Common situations: Running an upgrade twice (task already deleted the first time); non-elevated shell removing a task registered by an elevated context; the batch errorlevel-logic bug turning every successful deletion into an error.

Related errors

AI-assisted analysis of coreybutler/nvm-windows@5b18223ca1 (2026-08-15). Data as JSON: /api/errors/b73d5e96405f3c77. Report an issue: GitHub.