Repository navigation
Transcription for the host stops, when ANY runspace in the host get closed #2334
Description
Steps to reproduce
Start-Transcript -Path foo.txt -Force
$rs = [system.management.automation.runspaces.runspacefactory]::CreateRunspace()
$rs.open()
$ps = [System.Management.Automation.PowerShell]::Create()
$ps.Runspace = $rs
$ps.Dispose()
"Before Dispose"
$rs.Dispose()
"After Dispose"
Stop-TranscriptExpected behavior
No errors, the whole transcript (including "After Dispose") should be in the foo.txt file
Actual behavior
Stop-Transcript : An error occurred stopping transcription: The host is not currently transcribing.
At line:1 char:1
+ Stop-Transcript
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Stop-Transcript], PSInvalidOperationException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.StopTranscriptCommand
"After Dispose" is not in the foo.txt file
Environment data
Windows.
> $PSVersionTable
Name Value
---- -----
PSEdition Core
PSVersion 6.0.0-alpha
CLRVersion
GitCommitId v6.0.0-alpha.10
WSManStackVersion 3.0
BuildVersion 3.0.0.0
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1Also verfied in inbox
Name Value
---- -----
PSVersion 5.1.14393.187
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.187
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
cc Aditya Patwardhan (@adityapatwardhan) Lee Holmes (@LeeHolmes) Paul Higinbotham (@PaulHigin)
Activity
Fitzroy87 commentedon Oct 10, 2016
sergei (@vors) - does this issue account for the undesired behaviour documented in this uservoice post? https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/14745750-ps-5-0-bug-transcript-stops-after-restarting-a-re
I posted that bug on uservoice sometime ago. I have since had to edit all my scripts to include a wrapper around restart-computer in order to start a prematurely terminated transcript upon completion of restarting a remote computer. Most frustrating as this behaviour was not exhibited prior to WMF 5.0.
vors commentedon Oct 10, 2016
Fitzroy87 my wild guess is yes. These two are likely related.
Fitzroy87 commentedon Oct 10, 2016
sergei (@vors) Thank you. Apologies for polluting the discussion with a novice question - but in order for me to test the fix should I use WMF 5.1 or a 6.0 alpha build?
vors commentedon Nov 20, 2016
Fitzroy87 the issue is still open, which mean that it's still present in the
masterbranch.24 remaining items
MaximoTrinidad commentedon Dec 8, 2018
No issues experience with PowerShell Core GA v6.1.1 or Preview version 6.2.0-preview.2.
It's only in Windows PowerShell 5.1 and it won't be fix as all changes are been done for PowerShell Core moving forward.
potatoqualitee commentedon Dec 8, 2018
I saw it was fixed in 6, just hoping it could mayyyybe get fixed in the version that most of our people use 🤞
vexx32 commentedon Dec 8, 2018
From what I've been told there's going to be basically no more fixes backported to PS5.1, I'm afraid.
Your best bet is to submit a request on the uservoice site for Windows PowerShell, but from what I've heard there are no guarantees anything more will be done with Windows PowerShell. 🙁
MaximoTrinidad commentedon Dec 11, 2018
Rain Sallow (/u/ta11ow) (@vexx32)
Yes! There's no guarantees, but it helps identify bugs for PowerShell Core.
Bugs found in Windows PowerShell are been fix in PowerShell Core, as Windows PowerShell is complete. Microsoft was clear on this statement that they stop doing work in Windows PowerShell. So, 5.1 is the last version.
So, if there's any bug found in Windows PowerShell, it should repro in Core so it can be fix moving forward.
I have to say, now is a good time to truly test PowerShell Core, alongside Windows PowerShell, to help cleaning up what's missing. As, down the road, PowerShell Core will substitute Windows PowerShell.
:)
vexx32 commentedon Dec 11, 2018
Indeed, no argument there, but as has already been mentioned, this particular issue seems to have been fixed for Core already. 😄
SteveL-MSFT commentedon Dec 18, 2018
Since this specific issue is security related, we did make a fix in Windows PowerShell 5.1, but it'll only be available in newest Win10 builds.
alexandair commentedon Dec 19, 2018
Steve Lee (@SteveL-MSFT) Could you define the "newest Win10 build"?
I have
PSVersion: 5.1.17763.134andwinverreturnsVersion 1809 (OS Build 17763.194).The issue is still present.
PS Could someone explain to me
.134in PSVersion and.194in winver's output? Shouldn't that be the same number?SteveL-MSFT commentedon Dec 19, 2018
The last two digits in the version are updated automatically by the build system. You should just consider it magic and not rely on it. "Newest" here specifically means I believe the fix was checked in late last week so unless whenever that builds goes out to the Insider flights. Without going into details, it's complicated how a fix we make in our working branch in Windows ends up into a flighted build. It can take weeks.
alexandair commentedon Dec 19, 2018
I hope PowerShell team is aware how very confusing all this is. And, if it's confusing to someone who is involved as much as I am, I don't understand how regular PowerShell users can keep track on all this.
Version numbers that are not actually representing builds, inconsistent version numbers... If something is fixed in the insider build, that's not actually fixed for the most users. Majority of users care about the production-ready builds, and insider builds are not ready for a production. 1809 build showed us that even that one wasn't ready for a couple of months. :(
potatoqualitee commentedon Dec 19, 2018
That is good news, thank you Steve Lee (@SteveL-MSFT)! I will let people know.
PaulHigin commentedon Dec 19, 2018
Aleksandar Nikolić (@alexandair) Yes, this is unfortunately a confusing process. The fix was ported to a low level internal branch on 12/12 last week, and as Steve Lee (@SteveL-MSFT) mentioned, will propagate to a vNext flighting branch in a few weeks.
I doubt the fix would meet the bar for back porting to servicing branches (i.e., a patch), especially since the change in behavior can be viewed as a breaking change.
thecliguy commentedon Dec 19, 2018
Paul Higinbotham (@PaulHigin) How is fixing it a breaking change when in fact the introduction of this issue was a breaking change for scripts written against all versions of Powershell prior to 5.0 (which is when it was first introduced)?
The particular effect of this issue that I'm referring to is documented here (a UserVoice issue I raised in 2016): https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/14745750-ps-5-0-bug-transcript-stops-after-restarting-a-re
PaulHigin commentedon Dec 19, 2018
thecliguy Good point. But the new behavior is not exactly the same as before, although I believe it is now correct. Probably unlikely, but I worry about possible regressions when patching to live systems.
HammadKamran commentedon May 15, 2020
Hi, the issue seems to have poped back up.
Replace Transcription by *> redirection