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-Transcript
No errors, the whole transcript (including "After Dispose") should be in the foo.txt file
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
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.1
Also 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 @adityapatwardhan @LeeHolmes @PaulHigin
@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.
@Fitzroy87 my wild guess is yes. These two are likely related.
@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?
@Fitzroy87 the issue is still open, which mean that it's still present in the master branch.
@chunqingchen I'm assigning this to you since you're already touching the transcription code
This issue has been resolved fixed and verified
Is this only going to be fixed in PS6?


Is there anything we can do locally to fix it? Perhaps some override?
omg uh, i have no idea how i unassigned anyone 馃槓 sorry @chunqingchen !
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.

I saw it was fixed in 6, just hoping it could mayyyybe get fixed in the version that most of our people use 馃
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. 馃檨
@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.
:)
Indeed, no argument there, but as has already been mentioned, this particular issue seems to have been fixed for Core already. 馃槃
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.
@SteveL-MSFT Could you define the "newest Win10 build"?
I have PSVersion: 5.1.17763.134 and winver returns Version 1809 (OS Build 17763.194).
The issue is still present.
PS Could someone explain to me .134 in PSVersion and .194 in winver's output? Shouldn't that be the same number?
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.
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. :(
That is good news, thank you @SteveL-MSFT! I will let people know.
@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 @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.
@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
@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.
Hi, the issue seems to have poped back up.


Most helpful comment
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.