Es kann sich auf VS Code oder die PowerShell-Erweiterung von VS Code beziehen. Nach dem Neustart meines Systems konnte ich PowerShell sofort und ohne Probleme öffnen. Bei geöffnetem VS-Code weigern sich nicht administrative Sitzungen von PowerShell, geöffnet zu bleiben. Selbst nach dem Schließen von VS Code scheint PowerShell das zuverlässige Öffnen zu verweigern.

Sie können PowerShell Core über cmd.exe ausführen und eine Fehlermeldung anzeigen.

Wenn ich versuche, PWSH an der Eingabeaufforderung über CMD zu öffnen, wird PowerShell ordnungsgemäß gestartet. Selbst wenn diese PowerShell-Sitzung geöffnet ist, führt der Versuch, sie über ein Taskleistensymbol zu öffnen, dazu, dass sie nicht geöffnet wird. Ich habe auch versucht, PWSH in eine Explorer-Adressleiste einzugeben und das gleiche Ergebnis ohne Öffnen zu erhalten.

Wenn Sie nicht öffnen, geschieht dies. Ein Fenster öffnet sich und enthält die Header-Informationen:
`` `
PowerShell 6.2.0
Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten.

https://aka.ms/pscore6-docs
Geben Sie 'help' ein, um Hilfe zu erhalten.
`` ``
Die Eingabeaufforderung wird nie angezeigt und nach einer kurzen Verzögerung wird das Fenster geschlossen.

Wenn ich das System für eine Weile verlasse (Minuten, vielleicht 10 Minuten, aber ich mache weiterhin andere Aufgaben auf dem System), funktioniert das Öffnen von PowerShell einwandfrei. Ich konnte das Muster irgendwie wiederholen. Nachdem PowerShell ordnungsgemäß geöffnet wurde, schließe ich VS-Code (falls er überhaupt geöffnet war), warte ein wenig, öffne VS-Code erneut, warte ein wenig (möglicherweise eine Minute), und dann kann PowerShell nicht mehr geöffnet werden. Dies bleibt einige Zeit lang bestehen .

Ich habe letzte Nacht versucht, dies alles auf meiner 19H1-Insider-Maschine zu wiederholen, und es würde sich nicht nach dem ersten Mal wiederholen. Das erste Öffnen von PowerShell schlug fehl, aber jedes weitere Mal funktionierte auch nach einem Neustart.

Wenn ich versuche, PWSH über CMD an der Eingabeaufforderung zu öffnen,

Immer?

Wenn Sie das PowerShell Core-Ausgangsverzeichnis öffnen und auf pwsh.exe doppelklicken, startet es jederzeit gut?

Wenn ich versuche, PWSH über CMD an der Eingabeaufforderung zu öffnen,

Immer?

Bisher. Ich würde ein PWSH-Fenster ausprobieren, es würde fehlschlagen, ich würde CMD öffnen, PWSH eingeben, es würde gut starten, ein anderes PWSH-Fenster versuchen, es würde fehlschlagen. Beenden Sie die CMD-Instanz von PWSH und versuchen Sie es erneut. Sie wird problemlos wieder geöffnet. Ich würde es immer wieder wiederholen, das CMD-Fenster vollständig schließen und von vorne beginnen. Trotzdem scheint PWSH an einer CMD-Eingabeaufforderung immer zu funktionieren.

Ich werde auch nicht ganz schwören, dass selbst nach dem erfolgreichen Öffnen einer Instanz eines PWSH-Fensters einige Minuten später ein erneuter Versuch unternommen wird und es sich ohne besonderen Grund, den ich bisher ableiten kann, nicht wieder öffnen lässt.

Wenn Sie das PowerShell Core-Ausgangsverzeichnis öffnen und auf pwsh.exe doppelklicken, startet es jederzeit gut?

Es scheint der gleiche Zustand ohne Öffnung zu sein. Dies ist jedoch seltsam, da das direkte Klicken auf die EXE-Datei die meiste Zeit zu demselben Zustand ohne Öffnen führt, das Klicken auf die im Startmenüordner gespeicherte Verknüpfung jedoch sporadischer erscheint und häufig erfolgreich, aber definitiv nicht immer geöffnet wird .

Das Windows-Betriebssystem behält Fensterparameter für jede (Konsolen-) Anwendung bei. Es scheint, dass die Parameter defekt sind und wir sie aus der Registrierung bereinigen müssen.

Ich erlebe das auch. Wenn es hilft, wird in der Ereignisanzeige Folgendes angezeigt:

Source: .NET Runtime
Application: pwsh.exe
CoreCLR Version: 4.6.27317.3
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FF93A6B298E (00007FF93A6B0000) with exit code 80131506.

Source: Application Error
Faulting application name: pwsh.exe, version: 6.2.0.0, time stamp: 0x5c410542
Faulting module name: coreclr.dll, version: 4.6.27317.3, time stamp: 0x5c40be0f
Exception code: 0xc0000005
Fault offset: 0x000000000000298e
Faulting process id: 0x4f48
Faulting application start time: 0x01d4f30cd62ddac2
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 532d875c-683f-4640-bf93-310d5de00cb4
Faulting package full name: 
Faulting package-relative application ID: 

Genau wie bei @cpmcgrath kann ich bestätigen, dass im Anwendungsereignisprotokoll unmittelbar nach einem fehlgeschlagenen Start dasselbe
(2 Veranstaltungen)

Application: pwsh.exe
CoreCLR Version: 4.6.27317.3
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFFDDAB298E (00007FFFDDAB0000) with exit code 80131506.

Faulting application name: pwsh.exe, version: 6.2.0.0, time stamp: 0x5c410542
Faulting module name: coreclr.dll, version: 4.6.27317.3, time stamp: 0x5c40be0f
Exception code: 0xc0000005
Fault offset: 0x000000000000298e
Faulting process id: 0xc60
Faulting application start time: 0x01d4f3a7d85fc982
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 2d4862a8-7e13-4eeb-8d60-4ec7e2e74f30
Faulting package full name: 
Faulting package-relative application ID: 

Ich sehe immer noch, dass dies mit dem Öffnen von VS-Code mit der PowerShell-Vorschau-Erweiterung zusammenhängt, aber ich nehme an, dass andere Anwendungen, die .Net verwenden, diese Bedingung ebenfalls einrichten könnten.

@msftrncs Könnten Sie bitte den Debug-Build kompilieren und ausführen, um weitere Informationen zu erhalten? Es wäre auch schön, Repo-Schritte von Ihnen zu bekommen, damit wir das Problem auf einem sauberen System reproduzieren können.

Ich habe das gleiche Problem.

Quelle: Anwendungsfehler

Faulting application name: pwsh.exe, version: 6.2.0.0, time stamp: 0x5c410542
Faulting module name: coreclr.dll, version: 4.6.27317.3, time stamp: 0x5c40be0f
Exception code: 0xc0000005
Fault offset: 0x000000000000298e
Faulting process id: 0x4e64
Faulting application start time: 0x01d520380945a490
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 0fe828fd-a45e-4dc2-b7f0-77b07ecdba93
Faulting package full name: 
Faulting package-relative application ID: 

Quelle: .NET Runtime

Application: pwsh.exe
CoreCLR Version: 4.6.27317.3
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFC0240298E (00007FFC02400000) with exit code 80131506.

Ich habe die von Windows Error Reporting gesammelten Informationen angehängt.
Report.zip

Beobachtungen:

• Ich verwende Windows v1903 (OS Build 18362.30)
• Ich habe Visual Studio Code (v1.35.0) mit der Powershell-Erweiterung (v2019.5.0) installiert.
• Es scheint nach einem Neustart zu passieren
• Die Ladezeit des Profils scheint eine Weile zu dauern
• Es passiert manchmal im Adminsitrative-Modus und manchmal nicht
• Ich habe das Modul postgit als Teil meines Profils installiert, das unten definiert ist:

Import-Module posh-git

# Customise the Prompt
$GitPromptSettings.DefaultPromptPrefix.Text = '$((Get-Date).ToShortTimeString()) ';
$GitPromptSettings.DefaultPromptPrefix.ForegroundColor = [ConsoleColor]::Magenta;
#$GitPromptSettings.DefaultPromptSuffix.Text = ' $(GitVersionForCurrentRepoPrefixed)`r`nλ ';
$GitPromptSettings.DefaultPromptSuffix.Text = '`r`nλ ';

@ Antaris Danke! Ist Ihr Repo hartnäckig? Können Sie mit dem neuesten PowerShell Core-Build repo?

Es ist nicht hartnäckig, eher intermittierend. Ich werde versuchen, den neuesten Build herunterzuladen und zu sehen, ob dies das Problem behebt.

@Antaris Wenn Sie das Repo

@ SteveL-MSFT Sollten wir uns Sorgen um die Version 6.2 machen?

Nach einem fehlerhaften Modulnamen zu urteilen, habe ich das Gefühl, dass es sich um ein .NET-Problem handelt. Ähnliches ist schon mal passiert.
In der Zwischenzeit finden Sie hier eine einfache Möglichkeit, einen Speicherauszug des Absturzprozesses mit allen Details zu erstellen, die bei der Untersuchung und Behebung erheblich hilfreich sind. @Antaris - Sie können das ProcDump-Dienstprogramm ausprobieren:

Register as the Just-in-Time (AeDebug) debugger. Makes full dumps in c:\dumps.
C:\>procdump -ma -i c:\dumps

Beim nächsten Absturz von PS wird der Speicherauszug mit detaillierten Fehlerinformationen in den angegebenen Ordner geschrieben.

@anmenaga

Ich habe es heute Morgen geschafft, diese Erfahrung auszulösen. Neustart meines Laptops. Das erste Mal, als ich PowerShell Core öffnete, war es in Ordnung. Ich habe dann Visual Studio Code verwendet, um mein PS Core-Profil zu lesen, und ein Speichern initiiert, ohne Änderungen vorzunehmen. Ich habe dann PowerShell Core geöffnet und es wurde sofort geschlossen.

Dump-Datei ist hier:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Entschuldigung, ich hatte keine Zeit, dies gegen das aktuelle Commit zu testen. Ich werde versuchen, dies diese Woche zu erledigen

Es sieht so aus, als ob die Zugriffsverletzung unter TaskbarJumpList.CreateElevatedEntry .
@bergmeister ,

ExceptionAddress: 00007fff471f298e (coreclr!InteropSyncBlockInfo::GetRCWAndIncrementUseCount+0x000000000000000a)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000001
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000018
Attempt to read from address 0000000000000018

Partial stack:
coreclr!InteropSyncBlockInfo::GetRCWAndIncrementUseCount+0xa
coreclr!RCWHolder::Init+0x16
coreclr!ComObject::SupportsInterface+0x101
coreclr!ObjIsInstanceOf+0x482
coreclr!JITutil_ChkCastAny+0x95
coreclr!JITutil_ChkCastInterface+0x2e
Microsoft_PowerShell_ConsoleHost!Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry(System.String)+0x386
Microsoft_PowerShell_ConsoleHost!Microsoft.PowerShell.ConsoleHost+<>c.<Start>b__4_0()+0x14

Das würde erklären, warum dies nicht passiert, wenn ich pwsh über die Befehlszeile starte.

Wir haben bereits Berichte über sporadische Fehler gesehen, und andere Leute haben versucht, die COM-Anrufe zu verbessern. In diesem Fall vermute ich eher, dass der verwendete Windows Insider Build 19H1 ebenfalls ein Schuldiger sein könnte.
Ich habe den ursprünglichen C ++ - Code von Windows PowerShell mit denselben COM-Aufrufen nach C # portiert und den Windows Api Pack-Quellcode für die COM-Schnittstellendefinitionen verwendet.
Die gute Nachricht ist, dass dieser Code nur ausgeführt wird, wenn pwsh interaktiv gestartet wird, und dass die Registrierung des Jumplist-Menüs nur einmal erfolgen muss (es gibt Code, der dies implizit überprüft). Vielleicht sollten wir einen try {} catch-Block darum setzen und nur den Fehler-Stack-Trace abmelden?
Im Allgemeinen musste ich dabei den vollständigen .Net-Code des Windows Api Packs auf .Net Core portieren und optimieren, um einen Starthilfeeintrag mit Elevation zu ermöglichen. Vor 2 Wochen hat WPF den Quellcode für JumpList hinzugefügt und mit einer PR, um eine erhöhte Jumplist zu ermöglichen, konnten wir einen Großteil der Arbeit auf wenige Zeilen verschieben, aber letztendlich denke ich, dass es sich um ein .Net Core-Problem handelt.

@bergmeister bist du bereit diese

Ich kann versuchen, die WPF-API benötigt so etwas wie einen hinzugefügten booleschen Parameter (standardmäßig false), damit der Jumplist-Eintrag die Anwendung im erhöhten Modus öffnet. Es wird davon abhängen, wie flexibel die WPF-Leute in Bezug auf die Bereitschaft sind, die API-Änderung zu akzeptieren, und wie schwierig es ist, eine PR zusammenzuführen, aber ich denke, es wird ein Wettlauf gegen die Zeit sein, da .Net Core 3 um Juli einen RC veröffentlichen möchte (was bedeutet, dass sie solche Änderungen nach dieser Zeit weniger wahrscheinlich akzeptieren) ....
Andernfalls wäre die einzige Alternative, zu versuchen, den Fehler abzufangen (für mich sieht dies jedoch nach einem nicht abfangbaren, schwerwiegenden CLR-Fehler aus).
Ich selbst habe solche Fehler leider noch nie erlebt

Es scheint eine Rennbedingung in der GUI zu sein.

@ SteveL-MSFT Es ist nicht klar über 6.2 Version - sollten wir es auch beheben?

Ohne Daten zur Sicherung meiner nächsten Anweisung tritt dieses Problem anscheinend fast nie auf, wenn ich PowerShell mit "Als Administrator ausführen" öffne.

@jlouros Ich habe sowohl das Laufen ohne Erhöhungen als auch das Laufen als

Passiert das auch für PS 7-Preview1? .Net Core 3 hat die COM-Interaktion verbessert. Dies kann ein Problem von .Net Core 2.1 sein.
Außerdem: Vielleicht könnte auch eine ähnliche Verbesserung des Codes ähnlich wie bei PR # 7580 helfen?

@bergmeister , ich habe es auch mit 7 Preview passieren lassen, aber viel seltener. 7 Vorschau scheint einen CLR-Fehler-Dump zu geben, aber er wird so schnell geschlossen ... aber ich habe es verstanden:

Ich erlebe dies auch nicht annähernd so oft, wenn ich "als Administrator" laufe , wie @Antaris sagte, passiert es immer noch gelegentlich.

Wir könnten mehr Informationen mit dem Debug-Build erhalten (wir ignorieren Fehler beim Release-Build im Code!)

@ SteveL-MSFT Ich habe einen API-Vorschlag in WPF geöffnet, um zuerst eine Abmeldung zu erhalten (die vorgeschlagene Änderung ist nicht fehlerhaft, sollte also in Ordnung sein) und einige Implementierungsdetails auf niedriger Ebene enthalten. Ich habe mir den WPF-Code selbst nicht im Detail angesehen, aber er sollte nicht zu schwierig sein (der schwierigste Teil könnte das Testen sein).
https://github.com/dotnet/wpf/issues/950
Dies wäre der Weg in die Zukunft für PowerShell 7, da ich den WPF-Code genauer lese. Ich werde versuchen, ihn mit meiner Implementierung zu vergleichen und zu prüfen, ob ich die COM-Aufrufe verbessern kann. Ich frage mich, ob dies ein Problem des AppartmentState ist MTA da ich den C ++ Windows PowerShell-Code im Grunde genommen in C # übersetzt und die Schnittstellendefinitionen aus der Windows-API verwendet habe, als ich die Implementierung ursprünglich durchgeführt habe

@bergmeister Ich denke

@ SteveL-MSFT Sind Sie sicher, dass eine schwerwiegende CLR-Ausnahme abgefangen werden kann? Das Überprüfen des Fixes ist schwierig, da ich keine Umgebung habe, in der ich dies reproduzieren kann. Ich könnte versuchen, eine Version von PowerShell mit diesem Fix zu erstellen und sie hier hochzuladen, damit die Leute in dieser Ausgabe sie testen.

@bergmeister das kann ich mir nicht

Ich sehe, dass wir Rückkehrcodes im Code ignorieren, die schlecht sein können.

[Bearbeiten] Ignoriere meinen vorherigen Kommentar, obwohl [PreserveSig] Attribute an mehreren Stellen falsch sind, während ich die PR veranlasste, sie zu beheben. Ich bemerkte, dass sie nur bei Schnittstellenmethoden falsch waren, die du nicht aufgerufen hast.

Ich habe die Änderungen hier, wenn Sie sowieso eine PR wollen, aber es sollte nicht die Quelle der Abstürze sein.

@weltkante Interessanterweise habe ich die Schnittstellendefinitionen aus dem ursprünglichen Windows-API-Paket übernommen (siehe z. B. hier ) und war mir dessen nicht bewusst. Ich bin kein Experte auf diesem Gebiet, aber wenn Sie der Meinung sind, dass Ihre Änderungen es besser machen, reichen Sie bitte eine PR ein.

@Antaris @jlouros @msftrncs @cpmcgrath
In PR # 9896 habe ich einen globalen Haken hinzugefügt und die Protokollierung hinzugefügt, um weitere Informationen zu erhalten.
Bitte laden Sie das MSI aus dem PowerShell-CI-windows Build dieser PR herunter. Wenn Sie mit dem System nicht vertraut sind, verwenden Sie einfach den direkten Link zum Build hier und klicken Sie auf die Schaltfläche oben rechts. Klicken Sie dann auf Artifacts und dann auf das Untermenü artifacts . Dadurch wird Ihnen eine Zip-Datei heruntergeladen, und darin befindet sich die MSI, eine benutzerdefinierte Version von PowerShell 7 aus dem letzten Commit im Master.

Bitte melden Sie, ob das Problem behoben ist. Wenn nicht, geben Sie die Protokollnachrichten an, die auf der PowerShell-Konsole gedruckt werden. Es werden alle Phasen abgemeldet, die der Code durchläuft. Wenn Sie eine Meldung im Format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. teilen Sie uns dies bitte mit, da dies bedeuten würde, dass die Anweisung catch den schwerwiegenden CLR-Fehler abfangen konnte (was ich derzeit bezweifle).
Dies ist nur ein Test-Build und nicht für eine unterstützte Verwendung vorgesehen.
UPDATE (19. Juni): Ich habe den Link zu einem neueren Build aktualisiert, der die Ausnahmen in der Task.Run -Anweisung abfangen sollte, wie es zuvor noch durchgesickert sein könnte.

@bergmeister Ich habe dieses Preview7-MSI installiert und werde mich bei Ihnen melden, wenn ich versuche, das Problem neu zu erstellen und es einige Tage lang als meine Haupt-Shell auszuführen

Ich sehe, dass wir Rückkehrcodes im Code ignorieren, die schlecht sein können.

@iSazonov wo siehst du das? Ich habe gerade die COM-Schnittstellendeklarationen sowie die aufrufende CreateElevatedEntry -Methode überprüft und konnte zumindest bei den tatsächlich verwendeten Methoden nichts offensichtlich Falsches feststellen. Es sieht so aus, als würden alle Methoden, die PreserveSig deklarieren, ihre Rückkehrcodes überprüfen (bei Methoden, die void zurückgeben und PreserveSig nicht deklarieren, wird der Rückkehrcode von der Interop-Schicht überprüft).

Das Nichtprüfen von Rückkehrcodes kann jedoch nicht zu AccessViolationException in coreclr führen. Wenn der Stacktrace von @anmenaga oben für das Problem repräsentativ ist, könnte es sich durchaus um einen weiteren Fehler in der Intercl-Ebene von coreclr handeln (es gab bereits einige).

Wenn Ihre Untersuchung nirgendwohin führt, lohnt es sich möglicherweise, jemanden von coreclr zu haben, der sich die Müllkippe ansieht. Der Stacktrace im internen Coreclr-Code sieht wirklich nicht so aus, als würde er falsch codierte Interop-Deklarationen aufrufen. Insbesondere wenn in der Kernklasse RCWHolder- Hilfsklasse die Zeile m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); für den mittleren Anruf von GetInteropInfoNoCreate NULL zurückgibt, ist es beim Abstürzen nicht wirklich weit gekommen. (Dies ist, was in der Müllkippe passiert ist, keine Ahnung, ob sein Vertreter.)

ich meine
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
Beim Release-Build ignorieren wir Fehlerergebnisse.

@iSazonov ah ok, dies ignoriert das

Ich habe mir gerade die Implementierung von WPF angesehen und der Code überprüft, ob es sich im STA-Apartmentzustand befindet. WPF-Threads befinden sich alle in STA, daher bin ich mir nicht sicher, ob diese Prüfung auf WPF zurückzuführen ist oder ob STA besser für die von uns getätigten COM-Aufrufe geeignet ist (PowerShell Core, sogar 7, befindet sich im MTA-Modus, da .Net Core in der Vergangenheit nicht unterstützt wird STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L

Normalerweise verwaltet COM die Wohnung für Sie. Wenn Sie nicht auf STA sind, erstellt CoCreateInstance einen dedizierten STA-Thread für die COM-Objekte, wenn sie als nur auf STA ausgeführt registriert sind.

PowerShell Core, sogar 7, befindet sich im MTA-Modus, da .Net Core STA in der Vergangenheit nicht unterstützt

Sie können einen Thread nicht einfach in STA umwandeln. Wenn Sie dies tun, benötigen Sie auch eine Nachrichtenschleife. Wenn Sie keine Windows-Nachrichtenschleife haben, sollten Sie wahrscheinlich nicht STA sein.

@ Antaris Danke. PS: Wenn Sie eine Meldung im Format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. teilen Sie uns dies bitte mit, da dies bedeuten würde, dass die Anweisung catch den schwerwiegenden CLR-Fehler abfangen konnte (was ich derzeit bezweifle).
In der Zwischenzeit vermute ich, dass dieser Fehler eher auf Computern mit unterschiedlichen Hardwarespezifikationen auftritt, ich habe mit 1, 4 und 16 CPU-Kernen müde. Kann jemand Details teilen?

@bergmeister Ich konnte das Problem in den letzten Tagen nicht replizieren. Ich werde dabei bleiben, da ich PowerShell ständig benutze.

Ich habe auch keine Ausnahmen festgestellt.

Als Referenz ist meine Spezifikationsmaschine:
Dell XPS 15 9570
Intel Core i7-8750H - 6 Core
32 GB RAM

Das ist gut, aber haben Sie jemals eine Nachricht in der Konsole gesehen, die so etwas wie sagt?
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
Nur wenn Sie es gesehen haben, ist dies der Beweis dafür, dass der schwerwiegende CLR-Fehler erfolgreich abgefangen werden konnte.

Ich kann diesen Fehler jedes Mal reproduzieren, wenn ich versuche, PowerShell auszuführen. Ich werde in 2 verschiedenen Szenarien beschreiben, im ersten funktioniert es ohne Probleme, im zweiten nicht.
Bei Bedarf kann ich mehr Protokolle oder Ausgaben bereitstellen.

Meine Hardware:

Lenovo Y520
Intel I7 7700HQ (2,8 GHz)
16 GB RAM
Samsung 512 970Pro SSD
WesternDigital WD10SPCX 1 TB Festplatte
Nvidia 1050TI GPU 4 GB

Meine Software:

Betriebssystem:
M $ Windows 10 - Version 1903 - OsBuild 18917.1000

VS-Code:
Version: 1.36.0-Insider (System-Setup)
Festschreiben: 68a7e5bc437b38d0281df0756997a25da2a2900c
Datum: 2019-06-18T18: 40: 22.519Z
Elektron: 4.2.4
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-Elektron.0
Betriebssystem: Windows_NT x64 10.0.18917

Power Shell:
$ PSVersionTable

Name Wert
---- -----
PSVersion 7.0.0-Vorschau.1
PSEdition Core
GitCommitId 7.0.0-Vorschau.1
Betriebssystem Microsoft Windows 10.0.18917
Plattform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Szenarien:

Szenario 1 :

Schritte :
1-versuchen Sie, mit der rechten Maustaste auf einen Ordner zu klicken und PowerShell-Vorschau 7 auszuwählen -> hier öffnen
Ergebnis:
funktioniert problemlos

Szenario 2:

Schritte :
1-Öffnen Sie einen VS-Code in einem pipenv-Ordner (virtualenv) (Klicken Sie mit der rechten Maustaste auf einen Ordner / ein Verzeichnis und wählen Sie Mit Code Insider öffnen).
2-Warten Sie, bis virtualenv initialisiert ist
3-versuchen Sie, mit der rechten Maustaste auf denselben Ordner zu klicken und PowerShell-Vorschau 7 auszuwählen -> hier öffnen (oder versuchen Sie, ihn über eine Verknüpfung auszuführen).
Ergebnis:
Gibt diesen Fehler und schließt:
Interner CLR-Fehler. (0x80131506)
bei Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
bei Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
bei System.Threading.Tasks.Task.InnerInvoke ()
bei System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
bei System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
bei System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
bei System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
bei System.Threading.ThreadPoolWorkQueue.Dispatch ()
bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

@usta Kannst du bitte beschreiben, was du mit 'pipenv (virtualenv)' meinst? Ich benutze Python nicht sehr oft. Da Sie sagen, dass Sie immer reproduzieren können, lesen Sie bitte meinen Kommentar unten, installieren Sie den benutzerdefinierten Build und melden Sie, ob er das Problem behebt:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta Kannst du bitte beschreiben, was du mit 'pipenv (virtualenv)' meinst? Ich benutze Python nicht sehr oft. Da Sie sagen, dass Sie immer reproduzieren können, lesen Sie bitte meinen Kommentar unten, installieren Sie den benutzerdefinierten Build und melden Sie, ob er das Problem behebt:
# 9295 (Kommentar)
@bergmeister
Es sieht so aus, als hätte dieser Fehler behoben (wenn ich das gleiche Problem habe, werde ich es hier erwähnen), danke

Ich kann es scheinbar nicht mit dem benutzerdefinierten Build reproduzieren, aber es war mit 7 Vorschau 1 ziemlich selten, aber 6.2 macht es sehr regelmäßig. Das Anwenden eines Patches auf einen benutzerdefinierten Build von 6.2 oder eine Reihe von Builds aus 6.2 kann nützlich sein. Das Hinzufügen des Debug / Try / Catch-In hat möglicherweise etwas wie eine zeitliche Ressourcenblockierung oder etwas anderes geändert.

cc @ TravisEz13 @adityapatwardhan Wir sollten in Betracht ziehen , die Änderung von

@bergmeister können wir diesen Bug bitte wieder öffnen?
Weil ich heute wieder den gleichen Fehler gemacht habe (mit dem, den du erwähnt hast (der benutzerdefinierte Build))
(oder vielleicht eine andere)

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Verpflichten
CoCreateInstance
AddObject
Interner CLR-Fehler. (0x80131506)
bei Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
bei Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
bei System.Threading.Tasks.Task.InnerInvoke ()
bei System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
bei System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
bei System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
bei System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
bei System.Threading.ThreadPoolWorkQueue.Dispatch ()
bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

PS C: \ Windows \ System32> $ PSVersionTable

Name Wert
---- -----
PSVersion 7.0.0-Vorschau2.25651
PSEdition Core
GitCommitId 7.0.0-Vorschau2.25651
Betriebssystem Microsoft Windows 10.0.18922
Plattform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

@usta Ja, ich stimme zu, wir sollten wieder öffnen (ich habe zwar keine Rechte, werde aber die Betreuer benachrichtigen). Vielen Dank für die Meldung und Bereitstellung des Protokolls. Jetzt wissen wir, dass das Problem in dieser Zeile auftritt (sollte es erneut auftreten, aber mit einem anderen Protokoll, in dem AddObject nicht die letzte Zeile vor dem Absturz ist, lassen Sie es uns wissen ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonov Dies bedeutet, dass PR # 9928 trotz anfänglicher positiver Berichte den schwerwiegenden CLR-Fehler, der mehrfach gemeldet wurde, nicht abfangen kann (alle Fehlerberichte haben denselben Fehler gemeldet). Obwohl es immer noch einen gewissen Wert hatte, einen globalen Fang für etwas zu machen, das nicht wesentlich ist, bleibt das Problem bestehen ... Mit den zusätzlichen Informationen könnte ich versuchen zu prüfen, ob wir defensiver codieren können, um nicht an diesen Punkt zu gelangen, an dem dies geschieht Problem tritt auf (was ich für einen Fehler im Coreclr selbst halte, lohnt es sich, dort ein Problem zu eröffnen?). Ansonsten kann ich mir nur vorstellen, diese Funktion über eine Umgebungsvariable zu deaktivieren (oder einige Informationen zu speichern, wenn die Jumplist bereits einmal ausgefüllt wurde, da sie danach bestehen bleibt. Ich bin mir nicht sicher, ob sie nach Windows-Updates bestehen bleibt ...). Lassen Sie mich wissen, was Sie tun denke / bevorzuge.
In einem ähnlichen Zusammenhang habe ich das folgende Problem und PR in WPF geöffnet, um die erforderlichen APIs hinzuzufügen, um den Code / die Verantwortung in diesem Repo in Zukunft radikal zu vereinfachen. Bisher wurde der PR jedoch nicht überprüft und das Problem wurde mit .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister jetzt habe ich immer wieder versucht den gleichen
Am Ende kann ich es reproduzieren, aber dieses Mal gibt es ein anderes Protokoll:

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Verpflichten
CoCreateInstance
AddObject
Ausnahme 'System.Runtime.InteropServices.InvalidComObjectException: COM-Objekt, das von der zugrunde liegenden RCW getrennt wurde, kann nicht verwendet werden.
at System.StubHelpers.InterfaceMarshaler.ConvertToNative (Objekt objSrc, IntPtr itfMT, IntPtr classMT, Int32-Flags)
bei Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
bei Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (String-Titel)
bei Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () 'mit Stack-Trace bei System.StubHelpers.InterfaceMarshaler.ConvertToNative (Objekt objSrc, IntPtr itfMT, IntPtr classMT, Int32-Flags)
bei Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
bei Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (String title)
bei Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () erfolgreich abgefangen.
PS C: \ Benutzer \ usta>

Bei Bedarf werde ich gerne einen anderen Build testen oder versuchen, andere Protokolle bereitzustellen (die möglicherweise diesen Fehler beheben müssen).

@bergmeister
Ich bin nicht einmal ein $ Technologie-Programmierer, aber nur aus Neugier braucht diese Zeile nicht auch eine zusätzliche Überprüfung, bevor sie an AddUserTasks übergeben wird?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87)
Ich meine, ist das nicht besser?
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
if (hResult <0)
{
pShortCutCollection.Clear ();
Debug.Fail ($ "nativePropertyStore konnte nicht zur Sammlung hinzugefügt werden: HResult '{hResult}'.");
Rückkehr;
}}

Ist es möglich zu erkennen, ob die Sprungliste bereits vorhanden ist (weiterhin besteht), und die Schritte zu überspringen, um sie in diesem Fall zu erstellen?

@usta nein, AddObject wird als ungültig deklariert und daher führt die Interop-Ebene die Prüfung durch (und löst eine Ausnahme aus).

@msftrncs Ich kenne keine verwaltete API, die das Lesen von Jumplisten offenlegt, daher vermute ich, dass die native API dies nicht einmal unterstützt, aber ich habe es nicht überprüft. In jedem Fall ist es falsch, nur auf Existenz zu prüfen. Dies würde dazu führen, dass Jumplists veraltet sind, wenn sich eine ihrer Eigenschaften ändert.

In beiden Fällen sollten Sie wahrscheinlich ein Problem mit coreclr zur weiteren Prüfung ansprechen, wenn Sie das Problem hier nicht beheben können (und ich bezweifle ernsthaft, dass das Hinzufügen von try / catch für eine Coreclr-Panik funktioniert oder eine gute Idee ist). Sie müssen doch einen Dump untersuchen. Das Szenario im Dump sieht für mich sicherlich wie ein Coreclr-Fehler aus. (Siehe meinen Kommentar oben für das, was in der Müllkippe schief geht.)

Ich habe ein Problem mit allen Details im CoreClr-Repo eröffnet. Vielleicht können sie uns helfen. Ich habe mir unseren Code noch einmal angesehen und es gibt keine defensivere Möglichkeit, eine API abzufragen, wenn die Jumplist bereits erstellt wurde. Wir erhalten nur die maximale Anzahl verfügbarer Slots und kehren bereits früh zurück, wenn nicht genügend Speicherplatz für die Jumplist vorhanden ist Alles, was wir tun können, ist, die Jumplist intern zwischenzuspeichern oder so etwas wie ein Feature-Flag zu haben, um den problematischen Code zur Erstellung der Jumplist zu überspringen (sobald der Jumplist-Eintrag erstellt wurde, bleibt er bestehen).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister Ich habe den neuesten täglichen Build ausprobiert und es sieht so aus, als könnte ich in diesem Build den Fehler nicht reproduzieren.
Ob es behoben ist oder der Grund für diesen Fehler weg ist.

PS C: \ Users \ usta> echo $ PSVersionTable

Name Wert
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition Core
GitCommitId 7.0.0-dailypreview2.26796
Betriebssystem Microsoft Windows 10.0.18922
Plattform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Alle: Das CoreClr-Team hat das Problem untersucht und das Problem besteht darin, dass die aufgerufenen COM-APIs ausschließlich STA sind (PS Core wird derzeit noch in MTA ausgeführt, bis # 7216 behoben ist) und das Coreclr keine Warnungen / Fehler bereitgestellt hat. Daher habe ich Änderungen vorgenommen, um die JumpList in einem STA-Thread zu erstellen, der hoffentlich die endgültige Auflösung sein sollte.
Bitte testen Sie erneut mit dem neuesten Build von PR # 9896 und geben Sie Feedback

Jeder: Das Update für dieses Problem wurde auf die aktuelle Version von 6.2.2 zurückportiert. Bitte aktualisieren Sie es und geben Sie Feedback, wenn es behoben wurde. Benutzer der Vorschau müssen auf 7.0.0-preview.2 warten
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

: tada: Dieses Problem wurde in # 10057 behoben, das nun erfolgreich als v7.0.0-preview.2 .: tada:

Praktische Links:

• Versionshinweise

: tada: Dieses Problem wurde in # 9928 v7.0.0-preview.2 .: tada:

Praktische Links:

• Versionshinweise