Skip to content

fix(harness): start child processes without NoDefaultCurrentDirectoryInExePath - #28

Merged
fadwen merged 1 commit into
mainfrom
fix/install-command-cwd
Oct 8, 2026
Merged

fadwen merged 1 commit into
mainfrom
fix/install-command-cwd

Conversation

@fadwen

@fadwen fadwen commented Oct 8, 2026

Copy link
Copy Markdown
Owner

Summary

A Win32 install or uninstall command given as a bare batch file (install.cmd) failed from Invoke-IntuneWin32AppTest with "'install.cmd' is not recognized as an internal or external command" on a machine where NoDefaultCurrentDirectoryInExePath is set in the caller's environment. That variable is a per-user shell setting that stops cmd.exe searching its working folder. The agent's cmd.exe runs as SYSTEM without the caller's profile and finds the file, so the local run disagreed with the device for a reason that had nothing to do with the app.

Changes

  • Private/Invoke-IslProcess.ps1: the direct child process starts without NoDefaultCurrentDirectoryInExePath, next to the existing PSModulePath handling of the same start info. The scheduled-task modes run under another account's environment and are unchanged.
  • Tests/Unit/Private/Invoke-IslProcess.Tests.ps1: a test sets the variable in the test session and checks that cmd.exe /C "install.cmd" still runs the batch file in its working folder through the launcher.
  • CHANGELOG.md: Fixed entry under Unreleased.

Verification

  • Tests/Unit/Private/Invoke-IslProcess.Tests.ps1: 21 passed on PowerShell 7.6.6 and on Windows PowerShell 5.1 (Pester 6.2.0).
  • Full unit suite on PowerShell 7.6.6 with this and the two stacked changes applied: 907 passed, 2 skipped; on Windows PowerShell 5.1: 904 passed, 5 skipped.
  • PSScriptAnalyzer (Error, Warning) clean on the changed file; no line over 115 characters.

Notes

  • First of three stacked PRs; the batch-file warning PR is based on this branch.

…InExePath

With NoDefaultCurrentDirectoryInExePath set in the caller's environment, a
per-user shell setting, cmd.exe does not look in its working folder, so a
Win32 install command given as a bare batch file ("install.cmd") failed
with "'install.cmd' is not recognized" from Invoke-IntuneWin32AppTest. The
agent's cmd.exe runs without the caller's profile and finds the file.

The launcher now removes the variable from the direct child's environment,
next to the PSModulePath handling that already edits it. The scheduled-task
modes run under another account's environment and are unchanged.

@fadwen fadwen left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notes on the lines whose reason the diff does not show.

# With NoDefaultCurrentDirectoryInExePath set in the caller's own environment, cmd.exe does
# not look in its working folder, and a bare 'install.cmd' fails with "not recognized". The
# agent's cmd.exe runs without the caller's profile, so the child runs without the setting
$null = $startInfo.Environment.Remove('NoDefaultCurrentDirectoryInExePath')

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed unconditionally rather than only when set: Remove on a missing key returns false and nothing else, and the task modes below are left alone on purpose. A scheduled task runs with the SYSTEM or the other account's environment, where a caller's per-user setting is not present, which is also the environment the agent's own cmd.exe has.

# the working folder; the agent's cmd.exe has no such setting, so the child must not either
Set-Content -Path (Join-Path $TestDrive 'install.cmd') -Value '@echo ran' -Encoding ascii
$saved = $env:NoDefaultCurrentDirectoryInExePath
$env:NoDefaultCurrentDirectoryInExePath = '1'

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Set in the test's own process rather than mocked, because the thing under test is what the child inherits from the parent. Without the fix this exact run fails with "'install.cmd' is not recognized" (exit 1), which is how the problem showed up on a developer machine with the variable in the user environment.

@fadwen
fadwen added this pull request to stack #31 October 8, 2026 22:12
@fadwen
fadwen merged commit 26229c9 into main Oct 8, 2026
4 checks passed
@fadwen
fadwen deleted the fix/install-command-cwd branch October 8, 2026 22:27
@fadwen fadwen mentioned this pull request Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant