Write-Host statements, file redirections in a finally block intermittently fail quietly on Windows when Ctrl+C is used to terminate a Read-Host call

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest released version
Search the existing issues.
Refer to the FAQ.
Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

The problem isn't easy to reproduce, and I see it on Windows only - it may be specific to aborting a Read-Host call.
It may take several tries, suggesting some non-deterministic timing is at play, relating to when the finally block executes in relation to stopping the script.

Related: #19988

# Save to a file and run on *Windows*:
# Repeatedly run the following and press Ctrl-C when prompted.
# Then make sure that:
#   (a) 'Aborted.' prints
#   and (b) that file temp:/$PID.txt exists.
Remove-Item -ErrorAction Ignore temp:/$PID.txt
try {
  Read-Host 'Press Ctrl-C now'
}
finally {
  Write-Host "Aborted."
  Get-Date > temp:/$PID.txt
}

Expected behavior

Aborted. should print.
Running Get-Content temp:/$PID.txt afterwards should print the timestamp when Ctrl-C was pressed.

Actual behavior

Intermittently, Aborted. doesn't print.
More often, file temp:/$PID.txt isn't created.

The failure is always quiet.

Error details

No response

Environment data

PowerShell 7.4.0-preview.4 on Windows 11 22H2 (ARM64)

Visuals

No response

What if we replace Read-Host with another code?

Ilya (@iSazonov)

Good point, Ilya (@iSazonov) - the problem may be specific to Read-Host: I cannot reproduce the symptom when I use Start-Sleep or an external program that prompts for input instead. I've updated the initial post.

I just run into this issue yesterday and spent some time narrowing down the cause because of the extra complexity resulting from nested try-catch-finally blocks and what not.

It appers that not only Write-Host and file redirections are affected, but any command might not be executed in the finally block:

$global:try = 'N'
$global:finally1 = 'N'
$global:finally2 = 'N'
try {
        $global:try = 'Y'
        Read-Host 'Press Ctrl-C now'
} finally {
        $global:finally1 = 'Y'
        Start-Sleep -Milliseconds 100
        $global:finally2 = 'Y'
}

Results of running this script and pressing Ctrl-C when requested:

> .\finally-vs-read-host.ps1
Press Ctrl-C now:
> "$try $finally1 $finally2"
Y Y N

I.e. if running the commands in the finally block following the aborted Read-Host takes some time, then even simple variable assignments might not be executed.

Interestingly, it appears that in case of nested try-finally blocks after a short time interval the outer finally block(s) are executed properly, e.g. running:

$global:try = 'N'
$global:finally1 = 'N'
$global:finally2 = 'N'
try {
        $global:try = 'Y'
        try { Read-Host 'Press Ctrl-C now' }
        finally { Start-Sleep -Milliseconds 100 }
} finally {
        $global:finally1 = 'Y'
        Start-Sleep -Milliseconds 100
        $global:finally2 = 'Y'
}

always (well, maybe not always, but 25 consecutive times) resulted in:

> "$try $finally1 $finally2"
Y Y Y

All the above with PowerShell 7.3.6 on Windows 10.0.19044.

I'd like to revisit that code snippet with the nested try-finally blocks from my previous post to demonstrate that the inner finally block is only partially executed, but despite this the outer one is executed properly, even with a longer delay.

$global:try = 'N'
$global:nested_finally1 = 'N'
$global:nested_finally2 = 'N'
$global:finally1 = 'N'
$global:finally2 = 'N'
try {
        $global:try = 'Y'
        try {
                Read-Host 'Press Ctrl-C now'
        } finally {
                $global:nested_finally1 = 'Y'
                Start-Sleep -Milliseconds 100
                $global:nested_finally2 = 'Y'
        }
} finally {
        $global:finally1 = 'Y'
        Start-Sleep -Seconds 1    # Longer delay
        $global:finally2 = 'Y'
}

The results:

> .\PS-finally-vs-read-host.ps1
Press Ctrl-C now:
> "$try $nested_finally1 $nested_finally2 $finally1 $finally2"
Y Y N Y Y

When I removed the 100ms sleep from the inner finally block, then the values of the variables were Y Y Y Y N, indicating that this time it's the other way around, i.e. after the inner finally block was fully executed the outer was executed only partially.

I find this behavior quite bizarre, TBH. Anyway, I'll use this "nested try-finally block with a noop delay" trick as a workaround for the time being, because a hard coded 100ms delay after each Read-Host call hurts much less than the inconsistent state resulting from a partially executed cleanup.

This issue is still present in the current PowerShell version 7.5.2.

Toujours présent, aucune solution fiable lors d'un read-host ...

Navigation Menu

Repository navigation

`Write-Host` statements, file redirections in a `finally` block intermittently fail quietly on Windows when Ctrl+C is used to terminate a `Read-Host` call #19987

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Write-Host statements, file redirections in a finally block intermittently fail quietly on Windows when Ctrl+C is used to terminate a Read-Host call #19987

Description

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Activity

iSazonov commented on Jul 17, 2023

mklement0 commented on Jul 17, 2023

szeder commented on Sep 15, 2023

szeder commented on Sep 26, 2023

szeder commented on Aug 28, 2025

zornot commented on Jan 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`Write-Host` statements, file redirections in a `finally` block intermittently fail quietly on Windows when Ctrl+C is used to terminate a `Read-Host` call #19987