Skip to content

PowerShell ETW logging on windows needs to use a unique provider id and register the manifest. #4939

Description

Currently, PowerShell uses the same ETW provider GUID as PowerShell on Windows. This presents a few, subtle problems:
1: PowerShell 6 events cannot be easily distinguished from PowerShell/Windows.
2: PowerShell 6 is relying on a valid ETW manifest being registered to ensure events can be decoded. This assumption breaks on down-level systems that do not contain PowerShell/Windows 5.X and also ties PowerShell 6 to PowerShell/Windows events.
The solution is as follows:
1: Snapshot the PowerShell/Windows ETW manifest and update the provider GUID and Provider Name.

The Event viewer location should be moved outside the Microsoft/Windows event tree since PowerShell 6 does not ship inbox.
2: Provide a script or MSI action to register the PowerShell 6 manifest either at install time or as a post install, user step to address xcopy deploy use cases.
3: Document the updated Provider GUID, name, and any registration steps (if appropriate)consumers.

Activity

  1. lzybkr commented on Sep 28, 2017

    @lzybkr
    Contributor

    It might be worth moving to EventSource instead of using ETW directly - this would be useful on Linux/Mac.

  2. anmenaga commented on Sep 28, 2017

    @anmenaga

    What is the plan for several different PS versions installed side-by-side?

  3. SteveL-MSFT commented on Sep 28, 2017

    @SteveL-MSFT
    Member

    I think side-by-side PSCore should be fine in the same log as long as it can be filtered. PSCore and Windows PowerShell should be completely separate

  4. iSazonov commented on Sep 29, 2017

    @iSazonov
    Collaborator
  5. RichardSiddaway commented on Sep 29, 2017

    @RichardSiddaway

    Would it be possible to set up a PowerShell v6 source for each version so that side by side of multiple v6 versions could be differentiated

  6. SteveL-MSFT commented on Sep 29, 2017

    @SteveL-MSFT
    Member

    I believe the current thinking is to have PSCore6.x all in the same log, but should be easy to filter for a particular version.

  7. iSazonov commented on Sep 29, 2017

    @iSazonov
    Collaborator

    RichardSiddaway As Steve Lee (@SteveL-MSFT) said we can use a field to filter. The field can be PSVersion or GitCommitId.

  8. added this to the milestone on Sep 29, 2017
  9. mirichmo commented on Oct 10, 2017

    @mirichmo
    Member

    For reference: #1189. I looked into it a while ago and noted additional actions that must take place for PowerShell Core to support it.

  10. modified the milestones: , 6.0.0-RC on Nov 3, 2017
  11. daxian-dbw commented on Nov 9, 2017

    @daxian-dbw
    Member

    Dan Travison (@dantraMSFT) #5360 has been merged. Do you want to leave this issue open to track the manifest file clean up work?

  12. dantraMSFT commented on Nov 9, 2017

    @dantraMSFT
    ContributorAuthor

    No, I'll close it and create a separate issue. I don't know when we'll do the manifest cleanup since it depends on removing full CLRcode that references it.

    #5394

  13. dantraMSFT commented on Nov 9, 2017

    @dantraMSFT
    ContributorAuthor

    Actually, this needs to remain open until the PowerShell.Core.Instrumentation nuget package is published.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Resolution-FixedThe issue is fixed.WG-Enginecore PowerShell engine, interpreter, and runtime

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions