8000 Transcription for the host stops, when ANY runspace in the host get closed · Issue #2334 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

Transcription for the host stops, when ANY runspace in the host get closed #2334

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
vors opened this issue Sep 21, 2016 · 22 comments
Closed

Transcription for the host stops, when ANY runspace in the host get closed #2334

vors opened this issue Sep 21, 2016 · 22 comments
Labels
Issue-Bug Issue has been identified as a bug in the product Resolution-Fixed The issue is fixed. WG-Interactive-Debugging debugging PowerShell script
Milestone
6.0.0-NiceToHave

Comments

@vors
Copy link
Collaborator
vors commented Sep 21, 2016 •
edited
Loading

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-Transcript

Expected 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.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
@SteveL-MSFT SteveL-MSFT added the WG-Interactive-Debugging debugging PowerShell script label Sep 22, 2016
vors pushed a commit to vors/PowerShell that referenced this issue Sep 29, 2016
Replace Transcription by *> redirection
911c7d9 
due to the issue PowerShell#2334
@Fitzroy87
Copy link
Fitzroy87 commented 8000 Oct 10, 2016 •
edited
Loading

@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
Copy link
Collaborator Author
vors commented Oct 10, 2016

@Fitzroy87 my wild guess is yes. These two are likely related.

@Fitzroy87
Copy link

@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?

@SteveL-MSFT SteveL-MSFT added this to the 6.0.0 milestone Nov 4, 2016
@vors
Copy link
Collaborator Author
vors commented Nov 20, 2016

@Fitzroy87 the issue is still open, which mean that it's still present in the master branch.

@vors vors added the Issue-Bug Issue has been identified as a bug in the product label Nov 20, 2016
@SteveL-MSFT SteveL-MSFT modified the milestones: 6.0.0-beta, 6.0.0 Nov 21, 2016
@SteveL-MSFT SteveL-MSFT modified the milestones: 6.0.0-beta1, 6.0.0-beta2 Mar 16, 2017
@SteveL-MSFT SteveL-MSFT self-assigned this Apr 24, 2017
@SteveL-MSFT SteveL-MSFT modified the milestones: 6.0.0-beta, 6.0.0 May 15, 2017
@SteveL-MSFT SteveL-MSFT removed their assignment May 18, 2017
@SteveL-MSFT
Copy link
Member

@chunqingchen I'm assigning this to you since you're already touching the transcription code

@chunqingchen chunqingchen mentioned this issue May 31, 2017
Merged
@PaulHigin PaulHigin mentioned this issue Jun 2, 2017
Closed
@chunqingchen
Copy link
Contributor

This issue has been resolved fixed and verified

@iSazonov iSazonov added the Resolution-Fixed The issue is fixed. label Jun 16, 2017
@wsmelton wsmelton mentioned this issue Nov 22, 2017
Closed
6 tasks
@potatoqualitee
Copy link

Is this only going to be fixed in PS6?

image

image

Is there anything we can do locally to fix it? Perhaps some override?

@potatoqualitee
Copy link

omg uh, i have no idea how i unassigned anyone 😐 sorry @chunqingchen !

@MaximoTrinidad
Copy link

No issues experience with PowerShell Core GA v6.1.1 or Preview version 6.2.0-preview.2.

pwsh01_transcript_01_2018-12-08_11-19-24
pwsh01_transcript_02_2018-12-08_11-19-24

It's only in Windows PowerShell 5.1 and it won't be fix as all changes a 8000 re been done for PowerShell Core moving forward.

pwsh01_transcript_03_2018-12-08_11-19-24

@potatoqualitee
Copy link

I saw it was fixed in 6, just hoping it could mayyyybe get fixed in the version that most of our people use 🤞

@vexx32
Copy link
Collaborator
vexx32 commented 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
Copy link

@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
Copy link
Collaborator
vexx32 commented 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
Copy link
Member

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
Copy link
Contributor

@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?

@SteveL-MSFT
Copy link
Member

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
Copy link
Contributor

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
Copy link

That is good news, thank you @SteveL-MSFT! I will let people know.

@PaulHigin
Copy link
Contributor

@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.

@thecliguy
Copy link
thecliguy commented Dec 19, 2018 •
edited
Loading

@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
Copy link
Contributor

@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
Copy link

Hi, the issue seems to have poped back up.
image
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue-Bug Issue has been identified as a bug in the product Resolution-Fixed The issue is fixed. WG-Interactive-Debugging debugging PowerShell script
Projects
None yet
Milestone
6.0.0-NiceToHave
Development

No branches or pull requests
0