Il peut être lié à VS Code ou à l'extension PowerShell sur VS Code. Après avoir redémarré mon système, j'ai pu ouvrir immédiatement PowerShell sans problème. Avec VS Code ouvert, les sessions non administratives de PowerShell refusent de rester ouvertes. Même après la fermeture de VS Code, PowerShell semble refuser l'ouverture de manière fiable.

Vous pouvez exécuter PowerShell Core à partir de cmd.exe et voir un message d'erreur.

Lorsque j'essaie d'ouvrir PWSH à partir de CMD à l'invite, PowerShell démarre correctement. Même avec cette session de PowerShell ouverte, toute tentative de l'ouvrir à partir d'une icône de la barre des tâches empêche son ouverture. J'ai également essayé de taper PWSH dans une barre d'adresse d'Explorateur et d'obtenir le même résultat non ouvert.

En n'ouvrant pas, c'est ce qui se passe. Une fenêtre apparaît et contient les informations d'en-tête:
''
PowerShell 6.2.0
Copyright (c) Microsoft Corporation. Tous les droits sont réservés.

https://aka.ms/pscore6-docs
Tapez «aide» pour obtenir de l'aide.
`` ``
L'invite de commande n'apparaît jamais et après un court délai, la fenêtre se ferme.

Si je quitte le système pendant un certain temps (minutes, peut-être 10 minutes, mais je continue à faire d'autres tâches sur le système), alors l'ouverture de PowerShell fonctionne correctement. J'ai pu en quelque sorte répéter le modèle. Une fois que PowerShell s'est bien ouvert, je ferme VS Code (s'il était même ouvert), attendez un peu, rouvrez VS Code, attendez un peu (peut-être une minute), puis PowerShell échoue à s'ouvrir à nouveau, et cela reste encore pendant un certain temps .

J'ai essayé de répéter tout cela sur ma machine d'initiés 19H1 hier soir, et cela ne se répéterait pas après la première fois. La première ouverture de PowerShell a échoué, mais toutes les fois suivantes ont fonctionné, même après un redémarrage.

Lorsque j'essaye d'ouvrir PWSH à partir de CMD à l'invite,

Toujours?

Si vous ouvrez le répertoire de base de PowerShell Core et double-cliquez sur pwsh.exe - démarre-t-il correctement à tout moment?

Lorsque j'essaye d'ouvrir PWSH à partir de CMD à l'invite,

Toujours?

Jusque là. J'essaierais une fenêtre PWSH, cela échouerait, j'ouvrirais CMD, tapez PWSH, cela commençait bien, essayez une autre fenêtre PWSH, cela échouerait. QUITTER l'instance CMD de PWSH et réessayer, elle s'ouvrirait très bien. Je continuerais à répéter, fermant entièrement la fenêtre CMD, recommençant, toujours PWSH à une invite CMD semble toujours fonctionner.

De plus, je ne jurerai pas complètement que même après qu'une instance d'une fenêtre PWSH s'ouvre avec succès, en essayant à nouveau quelques minutes plus tard et elle ne s'ouvrira pas à nouveau, sans raison particulière que je puisse déduire jusqu'à présent.

Si vous ouvrez le répertoire de base de PowerShell Core et double-cliquez sur pwsh.exe - démarre-t-il correctement à tout moment?

Cela semble être la même condition de non-ouverture. C'est bizarre cependant, car cliquer directement sur le fichier EXE semble entraîner la même condition de non-ouverture la plupart du temps, mais cliquer sur le raccourci stocké dans le dossier du menu Démarrer semble plus sporadique, s'ouvrant souvent avec succès, mais certainement pas toujours .

Le système d'exploitation Windows conserve des paramètres de fenêtre pour chaque application (console). Il semble que les paramètres sont brisés et que nous devons les nettoyer du registre.

Je vis cela aussi. Si cela vous aide, ce qui suit apparaît dans l'Observateur d'événements:

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: 

Tout comme @cpmcgrath , je peux confirmer que je vois la même chose dans le journal des événements de l'application immédiatement après un échec de lancement:
(2 événements)

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: 

Je vois toujours cela lié à l'ouverture de VS Code avec l'extension PowerShell Preview, mais je suppose que d'autres applications utilisant .Net pourraient également configurer cette condition.

@msftrncs Pourriez-vous s'il vous plaît compiler et exécuter la version de débogage pour obtenir plus d'informations? De plus, il serait bien de vous demander les étapes du repo afin que nous puissions reproduire le problème sur un système propre.

Je rencontre le même problème.

Source: erreur d'application

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: 

Source: Runtime .NET

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.

J'ai joint les informations collectées par Windows Error Reporting.
Report.zip

Observations:

• J'utilise Windows v1903 (build du système d'exploitation 18362.30)
• J'ai installé Visual Studio Code (v1.35.0) avec l'extension Powershell (v2019.5.0)
• Cela semble se produire après un redémarrage
• Le temps de chargement du profil semble prendre un certain temps
• Cela se produit parfois en mode Administrateur, et parfois non
• J'ai le module postgit installé dans le cadre de mon profil, qui est défini ci-dessous:

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 Merci! Votre repo est-il persistant? Pouvez-vous repo avec la dernière version de PowerShell Core?

Ce n'est pas persistant, plus intermittent. Je vais essayer de télécharger la dernière version et voir si cela résout le problème.

@Antaris Si vous pouvez s'il vous plaît

@ SteveL-MSFT Doit-on s'inquiéter de la version 6.2?

A en juger par le nom du module défaillant, j'ai le sentiment que c'est un problème .NET. Une chose similaire s'est produite avant.
En attendant, voici un moyen simple d'obtenir un vidage du processus de plantage avec tous les détails qui aideront grandement à enquêter et à corriger. @Antaris - vous pouvez essayer l' utilitaire ProcDump :

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

La prochaine fois que PS plante, le vidage avec les informations d'erreur détaillées sera écrit dans le dossier spécifié.

@anmenaga

J'ai réussi à déclencher cette expérience ce matin. Nouveau redémarrage de mon ordinateur portable. La première fois que j'ai ouvert PowerShell Core, tout allait bien. J'ai ensuite utilisé Visual Studio Code pour lire mon profil PS Core et initié une sauvegarde _ sans apporter de modifications_. J'ai ensuite ouvert PowerShell Core et il s'est immédiatement fermé.

Le fichier de vidage est ici:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Désolé, je n'ai pas eu le temps de tester cela par rapport au commit actuel, je vais essayer de le faire cette semaine

Il semble que la violation d'accès provient de moins de TaskbarJumpList.CreateElevatedEntry .
@bergmeister , vous rappelez-vous des problèmes de stabilité avec cette fonction?

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

Cela expliquerait pourquoi cela ne se produit pas si je lance pwsh partir de la ligne de commande.

Nous avons vu des rapports d'échecs sporadiques auparavant et d'autres personnes ont essayé d'améliorer les appels COM. Dans ce cas, je soupçonne plutôt que le Windows Insider build 19H1 utilisé pourrait également être un coupable.
J'ai porté le code C ++ d'origine de Windows PowerShell vers C # en utilisant les mêmes appels COM et j'ai utilisé le code source du pack Windows Api pour les définitions d'interface COM.
La bonne nouvelle est que ce code ne s'exécute que lorsque pwsh démarre de manière interactive et que l'enregistrement du menu Jumplist ne doit se produire qu'une seule fois (il y a du code qui vérifie cela implicitement). Peut-être devrions-nous mettre un bloc try {} catch autour de lui et ne déconnecter que la trace de la pile d'échecs?
De manière générale, quand je l'ai fait, j'ai dû porter le code .Net complet du pack Windows Api vers .Net Core et l'ajuster pour permettre une entrée de démarrage avec élévation. Il y a 2 semaines, WPF a ajouté le code source de JumpList et avec un PR pour permettre un jumplist élevé, nous pourrions reporter une grande partie du travail à quelques lignes, mais finalement je pense que c'est un problème .Net Core.

@bergmeister êtes-vous prêt à entreprendre ce travail? S'il vous plaît :)

Je peux essayer, l'API WPF aura besoin de quelque chose comme un paramètre booléen ajouté (par défaut à false) pour que l'entrée de liste de sauts ouvre l'application en mode élevé. Cela dépendra de la flexibilité des gars de WPF en termes de volonté d'accepter le changement d'API et de la difficulté de fusionner un PR, mais je pense que ce sera une course contre la montre car .Net Core 3 veut publier une RC vers juillet (ce qui signifie qu'ils sont moins susceptibles d'accepter de tels changements après cette période) ...
Sinon, la seule alternative serait d'essayer d'attraper l'erreur (mais pour moi, cela ressemble à une erreur CLR irrécupérable et fatale).
Je n'ai moi-même malheureusement jamais connu de telles erreurs

Cela semble être une condition de concurrence dans l'interface graphique.

@ SteveL-MSFT Ce n'est pas clair à propos de la version 6.2 - devrions-nous le corriger aussi?

Sans aucune donnée pour sauvegarder ma prochaine déclaration, il semble que ce problème ne se produise presque jamais si j'ouvre PowerShell avec `` Exécuter en tant qu'administrateur ''

@jlouros J'ai expérimenté à la fois l'exécution non élevée et l'exécution en tant qu'administrateur

Cela se produit-il également pour PS 7-preview1? .Net Core 3 a amélioré l'interaction COM, cela pourrait être un problème de .Net Core 2.1.
Aussi: Peut-être qu'une amélioration similaire du code similaire à PR # 7580 pourrait également aider?

@bergmeister , je l'ai également fait avec 7 preview, mais beaucoup moins souvent. 7 L'aperçu semble donner un vidage d'erreur CLR, mais il se ferme si rapidement ... mais je l'ai compris:

Je ne ressens pas non plus cela autant en exécutant `` en tant qu'administrateur '', comme le mentionne @Antaris , cela se produit encore occasionnellement.

Nous pourrions obtenir plus d'informations avec la version de débogage (nous ignorons les erreurs de version de version dans le code!)

@ SteveL-MSFT J'ai ouvert une proposition d'API dans WPF pour obtenir d'abord une approbation (le changement proposé est sans rupture, donc ça devrait être OK) et j'ai inclus quelques détails d'implémentation de bas niveau. Je n'ai pas examiné le code WPF lui-même en détail mais cela ne devrait pas être trop difficile (la partie la plus difficile pourrait être le test)
https://github.com/dotnet/wpf/issues/950
Ce serait la voie à suivre pour PowerShell 7, alors que je commence à lire le code WPF plus en détail, je vais essayer de le comparer à mon implémentation et voir si je peux améliorer les appels COM, je me demande si c'est un problème du AppartmentState étant MTA parce que j'ai essentiellement traduit le code C ++ Windows PowerShell en C # et utilisé les définitions d'interface de l'API Windows lorsque j'ai initialement fait l'implémentation

@bergmeister Je pense que pour l'instant, la solution provisoire est peut-être de l'envelopper dans try ... catch pour que pwsh démarre au moins. Nous pouvons apporter ce correctif au service 6.2.x. Le correctif approprié peut venir plus tard.

@ SteveL-MSFT Etes-vous sûr qu'une exception CLR fatale peut être interceptée? La vérification du correctif sera difficile car je n'ai pas d'environnement où je peux reproduire cela. Je pourrais essayer de créer une version de PowerShell avec ce correctif et la télécharger ici afin que les personnes concernées par ce problème la testent?

@bergmeister Je ne peux pas le

Je vois que nous ignorons les codes de retour dans le code qui peuvent être mauvais.

[modifier] ignorer mon commentaire précédent, même si les attributs [PreserveSig] sont incorrects à plusieurs endroits, tout en faisant le PR pour les corriger, j'ai remarqué qu'ils n'étaient faux que sur les méthodes d'interface que vous n'avez pas appelées.

J'ai les changements ici si vous voulez quand même un PR, mais cela ne devrait pas être la source des crashs.

@weltkante Intéressant, j'ai pris les définitions d'interface du pack API Windows original (voir par exemple ici ) et je n'en étais pas conscient. Je ne suis pas un expert dans ce domaine, mais si vous pensez que vos modifications l'améliorent, veuillez soumettre un PR.

@Antaris @jlouros @msftrncs @cpmcgrath
Dans PR # 9896, j'ai ajouté une capture globale autour de lui et ajouté la journalisation pour obtenir plus d'informations.
Veuillez télécharger le MSI à partir de la version PowerShell-CI-windows de ce PR. Si vous n'êtes pas familier avec le système, utilisez simplement le lien direct vers la construction ici et cliquez sur le bouton en haut à droite, puis cliquez sur Artifacts puis sur le sous-menu artifacts . Cela vous téléchargera un zip et contient le MSI, qui est une version personnalisée de PowerShell 7 à partir du dernier commit de master.

Veuillez signaler si cela résout le problème et si ce n'est pas le cas, veuillez fournir les messages de journal qui sont imprimés sur la console PowerShell. Il déconnectera toutes les étapes par lesquelles le code passe. Si vous voyez un message au format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. veuillez nous le faire savoir car cela signifierait que l'instruction catch a pu détecter l'erreur CLR fatale (dont je doute pour le moment).
Ceci est juste une version de test et n'est pas destinée à une utilisation prise en charge.
MISE À JOUR (19 juin): J'ai mis à jour le lien vers une version plus récente qui devrait attraper les exceptions à l'intérieur de l'instruction Task.Run comme avant, elle aurait pu encore fuir.

@bergmeister J'ai installé ce MSI Preview7 et je vous répondrai au fur et à mesure que j'essaierai de recréer le problème, et de l'exécuter pendant quelques jours en tant que shell principal 👍

Je vois que nous ignorons les codes de retour dans le code qui peuvent être mauvais.

@iSazonov où CreateElevatedEntry et je n'ai rien trouvé de manifestement faux, du moins dans les méthodes qui sont réellement utilisées. Il semble que toutes les méthodes déclarant PreserveSig vérifient leurs codes de retour (les méthodes retournant void et ne déclarant pas PreserveSig ont leur code de retour vérifié par la couche d'interopérabilité).

Quoi qu'il en soit, ne pas vérifier les codes de retour ne peut pas conduire à AccessViolationException dans coreclr. Si le stacktrace de @anmenaga ci -

Si votre enquête ne mène nulle part, il peut être intéressant de demander à quelqu'un de coreclr de jeter un œil à la décharge. Le stacktrace étant dans le code coreclr interne ne ressemble vraiment pas vraiment à l'appel à des déclarations d'interopérabilité mal codées. En particulier, lorsque dans la classe d'assistance coreclr m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); renvoie NULL pour l'appel du milieu de GetInteropInfoNoCreate cela n'allait pas vraiment très loin pour faire l'appel en panne. (C'est ce qui s'est passé dans la décharge, aucune idée si son représentant.)

je veux dire
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
Dans la version de version, nous ignorons les résultats d'échec.

@iSazonov ah ok, cela n'ignore pas vraiment le résultat de l'échec, cela ne donne tout simplement pas de diagnostic. Il retourne toujours immédiatement, ce qui signifie que la tentative de création de l'entrée JumpList est abandonnée sans effectuer d'autres appels COM. Faire un retour ne peut certainement pas conduire au genre d'accident que nous voyons ici.

Je viens de jeter un œil à l'implémentation de WPF et son code vérifie qu'il est dans l'état d'appartement STA. Les threads WPF sont tous en STA, donc je ne suis pas sûr si cette vérification est due à WPF ou si STA est plus adapté aux appels COM que nous effectuons (PowerShell Core, même 7, est en mode MTA en raison du fait que .Net Core ne prend pas en charge historiquement STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

Généralement, COM gère le cloisonnement pour vous, si vous n'êtes pas sur STA, CoCreateInstance créera un thread STA dédié pour les objets COM s'ils sont enregistrés comme s'exécutant uniquement sur STA.

PowerShell Core, même 7, est en mode MTA en raison du fait que .Net Core ne prend généralement pas en charge STA

Vous ne pouvez pas simplement transformer un fil en STA, si vous faites cela, vous avez également besoin d'une boucle de message. Si vous n'avez pas de boucle de messages Windows, vous ne devriez probablement pas être STA.

@Antaris Merci. PS: Si vous voyez un message au format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. veuillez nous le faire savoir car cela signifierait que l'instruction catch a pu attraper l'erreur fatale CLR (dont je doute pour le moment).
En attendant, je soupçonne que cette erreur se produit plutôt sur des machines de spécifications matérielles différentes, je suis fatigué avec 1, 4 et 16 cœurs de processeur. Quelqu'un peut-il partager des détails?

@bergmeister Je n'ai pas pu reproduire le problème ces derniers jours. Je vais continuer, car j'utilise PowerShell constamment.

Je n'ai également rencontré aucune exception.

Pour référence, ma machine de spécification est:
Dell XPS 15 9570
Intel Core i7-8750H - 6 cœurs
32 Go de RAM

C'est bien, mais avez-vous déjà vu un message dans la console disant quelque chose comme
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
Ce n'est que si vous l'avez vu que ce sera la preuve que l'erreur fatale CLR pourrait être interceptée avec succès.

Je peux reproduire ce bogue à chaque fois si j'essaye d'exécuter PowerShell. Je décrirai dans 2 scénarios différents, dans le premier, cela fonctionne sans aucun problème, par contre avec le second non.
Si nécessaire, je peux fournir plus de journaux ou de sorties.

Mon matériel:

Lenovo Y520
Intel I7 7700HQ (2,8 GHz)
16 Go de RAM
SSD Samsung 512 970Pro
Disque dur WesternDigital WD10SPCX 1 To
GPU Nvidia 1050TI 4 Go

Mon logiciel:

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

Code VS:
Version: 1.36.0-insider (configuration du système)
Commit: 68a7e5bc437b38d0281df0756997a25da2a2900c
Date: 2019-06-18T18: 40: 22.519Z
Électron: 4.2.4
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-électron.0
Système d'exploitation: Windows_NT x64 10.0.18917

PowerShell:
$ PSVersionTable

Valeur du nom
---- -----
PSVersion 7.0.0-preview.1
PSEdition Core
GitCommitId 7.0.0-preview.1
Système d'exploitation Microsoft Windows 10.0.18917
Plateforme Win32NT
Versions compatibles PSC {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SérialisationVersion 1.1.0.1
WSManStackVersion 3.0

Scénarios:

Scénario 1 :

Pas :
1-essayez de faire un clic droit sur un dossier et sélectionnez PowerShell aperçu 7 -> ouvrir ici
Résultat :
fonctionne parfaitement sans aucun problème

Scénario2:

Pas :
1-ouvrez un VS Code dans un dossier pipenv (virtualenv) (faites un clic droit sur un dossier / répertoire et sélectionnez Ouvrir avec Code Insider)
2-attendez qu'il initialise virtualenv
3-essayez de faire un clic droit sur le même dossier et sélectionnez PowerShell aperçu 7 -> ouvrez ici (ou essayez de l'exécuter via un raccourci)
Résultat :
Donne cette erreur et ferme:
Erreur CLR interne. (0x80131506)
à Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
sur Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
à System.Threading.Tasks.Task.InnerInvoke ()
à System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
à System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
à System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
à System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
à System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
à System.Threading.ThreadPoolWorkQueue.Dispatch ()
à System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

@usta Pouvez-vous décrire ce que vous entendez par «pipenv (virtualenv)», je n'utilise pas beaucoup Python. Puisque vous dites que vous pouvez toujours reproduire, veuillez lire mon commentaire ci-dessous, installez la version personnalisée et veuillez signaler si elle le corrige:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta Pouvez-vous décrire ce que vous entendez par «pipenv (virtualenv)», je n'utilise pas beaucoup Python. Puisque vous dites que vous pouvez toujours reproduire, veuillez lire mon commentaire ci-dessous, installez la version personnalisée et veuillez signaler si elle le corrige:
# 9295 (commentaire)
@bergmeister
Il semble que celui-ci a corrigé ce bug (si j'ai rencontré le même problème, je le mentionnerai ici) merci

Je n'arrive pas à le reproduire avec la version personnalisée, mais c'était assez rare avec 7 preview 1, mais la 6.2 le fait très régulièrement. Il peut être utile d'appliquer un correctif à une version personnalisée de 6.2 ou à une série de versions de la 6.2. Le simple fait d'ajouter le debug / try / catch in pourrait avoir changé quelque chose comme le verrouillage des ressources liées au timing ou quelque chose.

cc @ TravisEz13 @adityapatward que nous devrions envisager de prendre le changement de @bergmeister en 6.2.2

@bergmeister pouvons-nous rouvrir ce bogue s'il vous plaît?
Parce que j'ai à nouveau rencontré le même bug aujourd'hui (avec celui que vous avez mentionné (la version personnalisée))
(ou peut-être un autre)

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Commettre
CoCreateInstance
AddObject
Erreur CLR interne. (0x80131506)
à Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
sur Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
à System.Threading.Tasks.Task.InnerInvoke ()
à System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
à System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
à System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
à System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
à System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
à System.Threading.ThreadPoolWorkQueue.Dispatch ()
à System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

PS C: \ Windows \ System32> $ PSVersionTable

Valeur du nom
---- -----
PSVersion 7.0.0-aperçu2.25651
PSEdition Core
GitCommitId 7.0.0-aperçu2.25651
Système d'exploitation Microsoft Windows 10.0.18922
Plateforme Win32NT
Versions compatibles PSC {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SérialisationVersion 1.1.0.1
WSManStackVersion 3.0

@usta Oui, je suis d'accord, nous devrions rouvrir (je n'ai pas les droits mais j'en informerai les responsables). Merci beaucoup d'avoir signalé et fourni le journal, maintenant nous savons que le problème se produit sur cette ligne (si cela devait se reproduire mais avec un journal différent où AddObject n'est pas la dernière ligne avant le crash, faites-nous savoir si ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonov Cela signifie que malgré les rapports positifs initiaux, le PR # 9928 n'est pas en mesure de détecter l'erreur CLR fatale qui a été signalée plusieurs fois (tous les rapports de bogue ont signalé la même erreur). Alors qu'il y avait encore une certaine valeur à faire une capture globale pour quelque chose qui n'est pas essentiel, le problème persiste toujours ... Avec les informations supplémentaires, je pourrais essayer de voir si nous pouvons coder de manière plus défensive pour éviter d'arriver à ce point où cela problème se produit (que je soupçonne d'être un bogue dans le coreclr lui-même, est-ce que cela vaut la peine d'ouvrir un problème là-bas?). Sinon, je ne peux que penser à désactiver cette fonctionnalité via par exemple une variable d'environnement (ou à stocker des informations si le jumplist a déjà été rempli une fois car il persiste par la suite, je ne sais pas s'il persiste après les mises à jour de Windows cependant ...) Faites-moi savoir ce que vous pense / préfère.
Dans le même ordre d'idées, j'ai ouvert le problème suivant et le PR dans WPF pour ajouter les API requises pour simplifier radicalement le code / la responsabilité dans ce repo à l'avenir, mais jusqu'à présent, le PR n'a pas été examiné et le problème a été étiqueté avec .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister maintenant j'ai essayé encore et encore de reproduire la même erreur.
À la fin, je peux le reproduire mais cette fois, cela donne un autre journal:

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Commettre
CoCreateInstance
AddObject
Exception «System.Runtime.InteropServices.InvalidComObjectException: l'objet COM qui a été séparé de son RCW sous-jacent ne peut pas être utilisé.
à System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, indicateurs Int32)
à Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
à Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (String title)
sur Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () 'avec trace de pile à System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, indicateurs Int32)
à Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
à Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (String title)
sur Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () intercepté avec succès.
PS C: \ Utilisateurs \ usta>

Si nécessaire, je serai heureux de tester une autre version ou d'essayer de fournir d'autres journaux (qui pourraient avoir besoin de surmonter ce bogue)

@bergmeister
Je ne suis même pas un programmeur de technologie, mais par curiosité, cette ligne n'a-t-elle pas également besoin d'une vérification supplémentaire avant de passer à AddUserTasks?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87)
Je veux dire, n'est-ce pas mieux quelque chose comme ça:
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
si (hResult <0)
{
pShortCutCollection.Clear ();
Debug.Fail ($ "Impossible d'ajouter nativePropertyStore à la collection: HResult '{hResult}'.");
revenir;
}

Est-il possible de détecter si la liste de sauts existe déjà (persiste) et de sauter les étapes pour la construire dans ce cas?

@usta non, AddObject est déclaré comme retournant void et donc la couche d'interopérabilité fera la vérification (et lèvera une exception)

@msftrncs Je ne connais aucune API gérée qui expose la lecture des jumplists, donc je soupçonne que l'API native ne la prend même pas en charge, mais je n'ai pas vérifié. De toute façon, la simple vérification de l'existence est erronée, cela rendrait les cavaliers obsolètes si l'une de leurs propriétés changeait.

Dans les deux cas, si vous ne pouvez pas résoudre le problème ici (et je doute sérieusement que l'ajout de try / catch pour une panique de coreclr ne fonctionne pas, ni une bonne idée), vous devriez probablement soulever un problème avec coreclr pour un examen plus approfondi. Vous avez une décharge à examiner après tout. Le scénario dans le dump ressemble certainement à un bug coreclr pour moi. (Voir mon commentaire ci-dessus pour ce qui ne va pas dans la décharge.)

J'ai ouvert un problème avec tous les détails du repo CoreClr, peut-être qu'ils peuvent nous aider. J'ai revu notre code et il n'y a pas de moyen plus défensif d'interroger une API si le jumplist a déjà été créé, nous n'obtenons que le nombre maximum d'emplacements disponibles disponibles et revenons déjà tôt s'il n'y a pas assez de place pour le jumplist , tout ce que nous pouvons faire est de mettre en cache la liste de cavaliers en interne ou d'avoir quelque chose comme un indicateur de fonctionnalité pour ignorer le code de création de liste de cavaliers problématique (une fois que l'entrée de liste de cavaliers a été créée, elle persiste).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister J'ai essayé la dernière version quotidienne et il semble que dans cette version, je n'ai pas pu reproduire le bogue.
Que ce soit corrigé ou que la raison de ce bogue ait disparu.

PS C: \ Utilisateurs \ usta> echo $ PSVersionTable

Valeur du nom
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition Core
GitCommitId 7.0.0-dailypreview2.26796
Système d'exploitation Microsoft Windows 10.0.18922
Plateforme Win32NT
Versions compatibles PSC {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SérialisationVersion 1.1.0.1
WSManStackVersion 3.0

Tout le monde: l'équipe CoreClr a étudié le problème et le problème est que les API COM qui sont appelées sont strictement STA (PS Core fonctionne actuellement toujours dans MTA jusqu'à ce que # 7216 soit résolu) et le coreclr n'a fourni aucun avertissement / erreur. Par conséquent, j'ai poussé des modifications pour créer la JumpList dans un thread STA, qui devrait, espérons-le, être la résolution finale.
Veuillez recommencer le test avec la dernière version de PR # 9896 et faire part de vos commentaires

Tout le monde: le correctif de ce problème a été rétroporté dans la version récente de 6.2.2 , veuillez mettre à jour et fournir des commentaires s'il l'a résolu. Les utilisateurs de l'aperçu devront attendre 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

: tada: Ce problème a été résolu dans # 10057, qui a maintenant été publié avec succès sous le nom v7.0.0-preview.2 .: tada:

Liens utiles:

• Notes de version

: tada: Ce problème a été résolu dans # 9928, qui a maintenant été publié avec succès sous le nom v7.0.0-preview.2 .: tada:

Liens utiles:

• Notes de version