Troubleshooting PowerShell Scripts That Do Not Run and Show No Error

Symptoms

PowerShell scripts can appear not to run when execution policy blocks the file, the process exits too quickly, the script is launched from the wrong working directory, errors are swallowed, profiles change behavior, or a scheduled/noninteractive context hides output from the operator.

Environment

Windows endpoints or servers running Windows PowerShell or PowerShell 7, including interactive consoles, scheduled tasks, RMM tools, and deployment agents.

Most Likely Causes

The most common causes are policy scope mismatch, blocked downloaded files, wrong shell version, missing module dependency, path quoting, relative-path assumptions, profile side effects, or the script handling errors with SilentlyContinue.

What to Check First

1. Confirm which PowerShell executable and version is actually launching the script.
2. Check execution policy at all scopes before changing anything.
3. Verify the script path, current directory, file unblock state, and user context.
4. Run with NoProfile and explicit error preferences to surface hidden failures.

Fix Steps

1. Confirm the shell version and policy scopes.

   Record the executable, PowerShell edition, and every execution-policy scope before attempting a bypass.

   Safe to run: read-only

   $PSVersionTable
   Get-ExecutionPolicy -List
   Get-Command powershell,pwsh -ErrorAction SilentlyContinue | Select-Object Name, Source, Version

2. Verify the script file and remove downloaded-file ambiguity.

   Check that the path is correct, the file exists, and Windows has not marked it as downloaded from the internet.

   Safe to run: read-only

   $ScriptPath = 'C:\Path\To\Script.ps1'
   Test-Path -LiteralPath $ScriptPath
   Get-Item -LiteralPath $ScriptPath | Select-Object FullName, Length, LastWriteTime
   Get-Item -LiteralPath $ScriptPath -Stream * -ErrorAction SilentlyContinue

3. Run the script in a clean process with loud error handling.

   Use NoProfile and explicit error settings so profile side effects and swallowed errors are easier to separate.

   Safe to run: read-only

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File 'C:\Path\To\Script.ps1' -Verbose
   pwsh.exe -NoProfile -File 'C:\Path\To\Script.ps1' -Verbose

4. Compare working directory and user context.

   Scripts that use relative paths often fail silently from schedulers, RMM tools, and deployment systems.

   Safe to run: read-only

   whoami
   Get-Location
   [Environment]::Is64BitProcess
   [Environment]::GetEnvironmentVariable('PATH','Process')

5. Capture transcript evidence before editing the script.

   A transcript makes the next failure reviewable and avoids guessing from a blank console.

   Changes system state: review before running

   $Transcript = Join-Path $env:TEMP ('script-debug-{0:yyyyMMdd-HHmmss}.log' -f (Get-Date))
   Start-Transcript -Path $Transcript
   & 'C:\Path\To\Script.ps1' -Verbose
   Stop-Transcript

Validation

• The same command either runs successfully or produces a captured error in a transcript or console.
• The final run records the expected PowerShell version, account, working directory, and policy scope.
• If a process-scoped execution-policy bypass was used, the machine and user policy scopes were not permanently changed.
• Any script edit is tested with a safe input set before being used against production targets.

Logs to Check

• PowerShell transcript path captured during the test
• Event Viewer > Applications and Services Logs > Windows PowerShell
• Event Viewer > Applications and Services Logs > Microsoft > Windows > PowerShell > Operational
• Scheduler, RMM, or deployment-agent logs if the script runs noninteractively

Rollback and Escalation

• Close the process used for a process-scoped execution-policy bypass; do not leave a persistent policy change behind.
• Remove temporary transcript files if they contain hostnames, usernames, paths, or operational details that should not be retained.
• Revert script edits if the clean-process test changes behavior unexpectedly.

Escalate When

• Escalate to the endpoint or policy owner before changing machine, user, or Group Policy execution-policy settings.
• Escalate to the script owner if the transcript shows swallowed errors, broad catch blocks, or destructive actions.
• Escalate before running the script against production if the script modifies services, registry, firewall, identity, files, or cloud resources.

Edge Cases

• A 32-bit host launched by an agent may see different registry and module paths than a 64-bit console.
• PowerShell 7 and Windows PowerShell 5.1 may load different modules or interpret commands differently.
• A downloaded file may be blocked by alternate data stream metadata even when execution policy looks permissive.
• Some scripts intentionally suppress errors with SilentlyContinue or empty catch blocks.

Notes from the Field

• Start with evidence from the exact launch context. Interactive success does not prove scheduled-task or RMM success.
• Prefer a process-scoped bypass for troubleshooting over persistent policy changes.
• A blank console is not a result. Capture transcript output or event logs before deciding the script did nothing.