Pode estar relacionado ao VS Code ou à extensão PowerShell no VS Code. Depois de reiniciar meu sistema, consegui abrir imediatamente o PowerShell sem problemas. Com o VS Code aberto, as sessões não administrativas do PowerShell se recusam a permanecer abertas. Mesmo depois de fechar o VS Code, o PowerShell parece se recusar a abrir de forma confiável.

Você pode executar o PowerShell Core do cmd.exe e ver uma mensagem de erro.

Quando tento abrir o PWSH do CMD no prompt, o PowerShell começa bem. Mesmo com essa sessão do PowerShell aberta, a tentativa de abri-la a partir de um ícone da barra de tarefas resulta na não abertura. Também tentei digitar PWSH em uma barra de endereços do Explorer e obtive o mesmo resultado de não abrir.

Ao não abrir, é o que acontece. Uma janela é exibida com as informações do cabeçalho:
`` `
PowerShell 6.2.0
Copyright (c) Microsoft Corporation. Todos os direitos reservados.

https://aka.ms/pscore6-docs
Digite 'ajuda' para obter ajuda.
`` ``
O prompt de comando nunca aparece e, após um breve atraso, a janela fecha.

Se eu deixar o sistema por um tempo (minutos, talvez 10 minutos, mas continuo fazendo outras tarefas no sistema), abrir o PowerShell funcionará bem. Consegui meio que repetir o padrão. Depois que o PowerShell está abrindo bem, eu fecho o VS Code (se estiver aberto), espero um pouco, reabra o VS Code, espero um pouco (talvez um minuto) e então o PowerShell falha ao abrir novamente, e isso permanece novamente por algum período de tempo .

Eu tentei repetir tudo isso na minha máquina de insiders 19H1 ontem à noite, e não repetia depois da primeira vez. A primeira vez que abriu o PowerShell falhou, mas todas as vezes subsequentes funcionou, mesmo após uma reinicialização.

Quando tento abrir o PWSH do CMD no prompt,

Sempre?

Se você abrir o diretório inicial do PowerShell Core e clicar duas vezes em pwsh.exe - ele começa bem a qualquer momento?

Quando tento abrir o PWSH do CMD no prompt,

Sempre?

Tão longe. Eu tentaria uma janela PWSH, iria falhar, eu abriria o CMD, digitaria PWSH, começaria bem, tentaria outra janela PWSH, iria falhar. SAIA da instância CMD do PWSH e tente novamente, ele abriria bem novamente. Eu continuaria repetindo, fechando a janela CMD inteiramente, recomeçando, ainda PWSH em um prompt CMD parece estar sempre funcionando.

Além disso, não vou jurar completamente que, mesmo depois de uma instância de uma janela PWSH ser aberta com sucesso, tente novamente alguns minutos depois e ela não abrirá novamente, sem qualquer razão particular que eu possa até agora deduzir.

Se você abrir o diretório inicial do PowerShell Core e clicar duas vezes em pwsh.exe - ele começa bem a qualquer momento?

Parece ser a mesma condição de não abertura. Isso é estranho, porque clicar diretamente no arquivo EXE parece resultar na mesma condição de não abrir na maioria das vezes, mas clicar no atalho armazenado na pasta do menu iniciar parece mais esporádico, muitas vezes abrindo com sucesso, mas definitivamente nem sempre .

O sistema operacional Windows mantém uma janela de parâmetros para cada aplicativo (console). Parece que os parâmetros estão corrompidos e precisamos limpá-los do registro.

Estou passando por isso também. Se ajudar, o seguinte aparecerá no Visualizador de eventos:

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: 

Assim como @cpmcgrath , posso confirmar que vejo a mesma coisa no log de eventos do aplicativo imediatamente após uma falha na inicialização:
(2 eventos)

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: 

Ainda estou vendo isso correlacionado à abertura do VS Code com a extensão de visualização do PowerShell, mas suponho que outros aplicativos que usam .Net podem configurar essa condição também.

@msftrncs Você poderia compilar e executar a compilação de depuração para obter mais informações? Também seria bom obter as etapas de repo de você para que possamos reproduzir o problema no sistema limpo.

Estou enfrentando o mesmo problema.

Fonte: Erro de aplicativo

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: 

Fonte: .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.

Anexei as informações coletadas pelo Relatório de Erros do Windows.
Report.zip

Observações:

• Estou executando o Windows v1903 (OS Build 18362.30)
• Eu tenho o Visual Studio Code instalado (v1.35.0) com a extensão Powershell (v2019.5.0)
• Parece que acontece após uma reinicialização
• O tempo de carregamento do perfil parece demorar um pouco
• Às vezes acontece no modo Adminsitrativo, às vezes não
• Eu tenho o módulo postgit instalado como parte do meu perfil, que é definido abaixo:

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λ ';

Obrigado @Antaris ! Seu repo é persistente? Você pode fazer repo com a última compilação do PowerShell Core?

Não é persistente, é mais intermitente. Vou tentar baixar a compilação mais recente e ver se isso corrige o problema.

@Antaris Se você pode, por favor, bifurcar o repo e construir - com o modo de depuração, você pode obter mais informações na exceção.

@ SteveL-MSFT Devemos nos preocupar com a versão 6.2?

Julgando pelo nome do módulo com falha, tenho a sensação de que é um problema do .NET. Coisa semelhante aconteceu antes.
Enquanto isso, aqui está uma maneira simples de obter um dump do processo de travamento com todos os detalhes que ajudarão muito a investigar e corrigir. @Antaris - você pode tentar o utilitário ProcDump :

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

Na próxima vez que o PS travar, o despejo com informações detalhadas do erro será gravado na pasta especificada.

@anmenaga

Consegui desencadear esta experiência esta manhã. Reiniciar meu laptop. A primeira vez que abri o PowerShell Core, estava tudo bem. Em seguida, usei o Visual Studio Code para ler meu perfil PS Core e iniciei um salvamento _sem fazer alterações_. Em seguida, abri o PowerShell Core e ele foi fechado imediatamente.

O arquivo de despejo está aqui:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Desculpe, não tive tempo de testar isso contra o commit atual, vou tentar fazer isso esta semana

Parece que a violação de acesso vem de menos de TaskbarJumpList.CreateElevatedEntry .
@bergmeister , você se lembra de algum problema de estabilidade com esta função?

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

Isso explicaria por que isso não acontece se eu lançar pwsh partir da linha de comando.

Já vimos relatos de falhas esporádicas dele antes e outras pessoas tentaram melhorar as chamadas COM. Nesse caso, eu suspeito que o Windows Insider usado, build 19H1, também pode ser o culpado.
Transformei o código C ++ original do Windows PowerShell para C # usando as mesmas chamadas COM e usei o código-fonte do pacote Windows Api para as definições da interface COM.
A boa notícia é que esse código só é executado quando o pwsh é iniciado interativamente e que o registro do menu jumplist precisa acontecer apenas uma vez (há um código que verifica isso implicitamente). Talvez devêssemos colocar um bloco try {} catch em torno dele e apenas efetuar logout do rastreamento de pilha de falha?
De modo geral, quando fiz isso, tive que portar o código .Net completo do Windows Api Pack para .Net Core e ajustá-lo para permitir uma entrada de início rápido com elevação. 2 semanas atrás, WPF adicionou o código-fonte para JumpList e com um PR para permitir um jumplist elevado, poderíamos adiar muito do trabalho para apenas algumas linhas, mas no final das contas eu acho que é um problema do .Net Core.

@bergmeister, você está disposto a assumir esse trabalho? Por favor :)

Posso tentar, a API WPF precisará de algo como um parâmetro booleano adicionado (padronizado como falso) para fazer a entrada jumplist abrir o aplicativo em modo elevado. Dependerá de quão flexíveis os caras do WPF são em termos de disposição para aceitar a mudança de API e quão difícil é obter um PR mesclado, mas acho que será uma corrida contra o tempo porque .Net Core 3 quer publicar um RC por volta de julho (o que significa que eles são menos propensos a aceitar tais mudanças após esse período) ....
Caso contrário, a única alternativa seria tentar detectar o erro (mas, para mim, isso parece um erro CLR fatal e não detectável).
Eu mesmo infelizmente nunca experimentei tais erros

Parece uma condição de corrida na GUI.

@ SteveL-MSFT Não está claro sobre a versão 6.2 - devemos corrigi-lo também?

Sem quaisquer dados para fazer backup da minha próxima declaração, parece que esse problema quase nunca acontece se eu abrir o PowerShell com 'Executar como Administrador'

@jlouros , experimentei tanto a execução não elevada quanto a execução como administrador

Isso também acontece com o PS 7-preview1? .Net Core 3 melhorou a interação COM, pode ser um problema de .Net Core 2.1.
Além disso: talvez uma melhoria semelhante no código semelhante ao PR # 7580 também possa ajudar?

@bergmeister , isso aconteceu com 7 preview também, mas com muito menos frequência. A visualização 7 parece fornecer um despejo de erro CLR, mas fecha tão rapidamente ... mas entendi:

Eu também não sinto isso tanto ao executar 'como administrador', como @jlouros menciona, mas como @Antaris disse, ainda acontece ocasionalmente.

Poderíamos obter mais informações com a compilação de depuração (ignoramos os erros na compilação de lançamento no código!)

@ SteveL-MSFT Abri uma proposta de API no WPF para obter uma aprovação primeiro (a alteração proposta não é interrompida, então deve ser OK) e incluí alguns detalhes de implementação de baixo nível. Não examinei o código WPF em detalhes, mas não deve ser muito difícil (a parte mais difícil pode ser o teste)
https://github.com/dotnet/wpf/issues/950
Este seria o caminho a seguir para o PowerShell 7, quando começar a ler o código WPF em mais detalhes, tentarei compará-lo com minha implementação e ver se posso melhorar as chamadas COM. Estou me perguntando se isso é um problema de AppartmentState sendo MTA porque basicamente traduzi o código C ++ do Windows PowerShell para C # e usei as definições de interface da API do Windows quando fiz a implementação originalmente

@bergmeister Acho que por enquanto, talvez a solução provisória seja embrulhar em try ... catch para que o pwsh pelo menos comece. Podemos usar essa correção para a manutenção 6.2.x. A correção adequada pode vir mais tarde.

@ SteveL-MSFT Tem certeza de que uma exceção CLR fatal pode ser detectada? Verificar a correção será difícil, pois não tenho um ambiente onde possa reproduzir isso. Eu poderia tentar construir uma versão do PowerShell com essa correção e carregá-la aqui para que as pessoas neste problema testem?

@bergmeister Não consigo reproduzir isso sozinho. Acho que a melhor opção pode ser, como você sugere, construir um privado e pedir a alguém que possa reproduzi-lo para experimentá-lo.

Vejo que ignoramos códigos de retorno no código que podem ser ruins.

[editar] desconsidere meu comentário anterior, embora [PreserveSig] atributos estejam errados em vários lugares, ao fazer o PR para corrigi-los, percebi que eles estavam errados apenas em métodos de interface que você não chamou.

Eu tenho as alterações aqui se você quiser um PR de qualquer maneira, mas não deve ser a origem dos travamentos.

@weltkante Interessante, peguei as definições de interface do pacote de API do Windows original (veja, por exemplo, aqui ) e não sabia disso. Não sou um especialista nesta área, mas se você acha que suas alterações o tornam melhor, envie um PR.

@Antaris @jlouros @msftrncs @cpmcgrath
No PR # 9896, adicionei uma captura global em torno dele e incluí o registro para obter mais informações.
Faça download do MSI da compilação PowerShell-CI-windows desse PR. Se você não está familiarizado com o sistema, basta usar o link direto para a compilação aqui e clicar no botão no canto superior direito, depois clicar em Artifacts e depois no submenu artifacts . Isso fará o download de um zip e lá está o MSI, que é uma versão personalizada do PowerShell 7 do último commit no master.

Informe se isso corrige ou não, forneça as mensagens de log que são impressas no console do PowerShell. Ele desconectará todos os estágios pelos quais o código passa. Se você vir uma mensagem no formato Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. , informe-nos porque isso significaria que a instrução catch foi capaz de capturar o erro CLR fatal (do qual duvido no momento).
Esta é apenas uma versão de teste e não se destina a nenhum uso compatível.
ATUALIZAÇÃO (19 de junho): Eu atualizei o link para uma compilação mais recente que deve capturar as exceções dentro da instrução Task.Run como antes, ela ainda poderia ter vazado.

@bergmeister Eu instalei aquele Preview7 MSI e entrarei em contato com você enquanto tento recriar o problema e o executo por alguns dias como meu shell principal 👍

Vejo que ignoramos códigos de retorno no código que podem ser ruins.

@iSazonov onde você vê isso? Acabei de fazer uma revisão das declarações da interface COM, bem como do método de chamada CreateElevatedEntry e não consegui encontrar nada obviamente errado, pelo menos nos métodos que são realmente usados. Parece que todos os métodos que declaram PreserveSig estão verificando seus códigos de retorno (métodos que retornam void e não declaram PreserveSig têm seus códigos de retorno verificados pela camada de interoperabilidade).

De qualquer forma, não verificar os códigos de retorno não pode levar a AccessViolationException em coreclr. Se o rastreamento de pilha de @anmenaga acima for representativo para o problema, pode muito bem ser outro bug na camada de interoperabilidade coreclr (já houve alguns)

Se a sua investigação não levar a lugar nenhum, pode valer a pena ter alguém do coreclr para dar uma olhada no depósito de lixo. O stacktrace estando no código coreclr interno realmente não se parece muito com a chamada de declarações de interoperabilidade codificadas incorretamente. Em particular, quando na classe auxiliar coreclr m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); retorna NULL para a chamada do meio de GetInteropInfoNoCreate então não foi muito longe ao fazer a chamada de travamento. (Foi o que aconteceu no lixão, não faço ideia se é seu representante.)

Quero dizer
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
Na versão de lançamento, ignoramos os resultados de falha.

@iSazonov ah ok, isso realmente não ignora o resultado da falha, apenas não fornece o diagnóstico. Ele ainda retorna imediatamente, o que significa que a tentativa de criar a entrada JumpList é abortada sem fazer mais chamadas COM. Fazer um retorno certamente não pode levar ao tipo de falha que estamos vendo aqui.

Acabei de dar uma olhada na implementação do WPF e seu código verifica se ele está no estado de apartamento do STA. Os threads do WPF estão todos no STA, então não tenho certeza se esta verificação é devido ao WPF ou se o STA é mais adequado para as chamadas COM que fazemos (PowerShell Core, mesmo 7, está no modo MTA devido ao .Net Core historicamente não suportar STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

Normalmente COM lida com o apartamento para você, se você não estiver no STA, então o CoCreateInstance criará um thread STA dedicado para os objetos COM se eles estiverem registrados como executando apenas no STA.

PowerShell Core, mesmo 7, está no modo MTA devido ao .Net Core historicamente não oferecer suporte a STA

Você não pode simplesmente transformar um thread em STA, se você fizer isso, você também precisará de um loop de mensagem. Se você não tem um loop de mensagens do Windows, provavelmente não deveria ser STA.

Obrigado @Antaris . PS: Se você vir uma mensagem no formato Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. , informe-nos porque isso significaria que a instrução catch foi capaz de capturar o erro CLR fatal (do qual duvido no momento).
Nesse ínterim, eu suspeito que esse erro acontece bastante em máquinas de especificações de hardware diferentes, cansei com 1, 4 e 16 núcleos de CPU. Alguém pode compartilhar detalhes?

@bergmeister Não consegui reproduzir o problema nos últimos dias. Vou continuar, já que uso o PowerShell constantemente.

Eu também não encontrei nenhuma exceção.

Para referência, minha máquina de especificações é:
Dell XPS 15 9570
Intel Core i7-8750H - 6 núcleos
32 GB de RAM

Isso é bom, mas você já viu uma mensagem no console dizendo algo como
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
Somente se você o tiver visto, é a prova de que o erro fatal do CLR pode ser detectado com êxito.

Posso reproduzir esse bug sempre que tentar executar o PowerShell. Vou descrever em 2 cenários diferentes, no primeiro está funcionando sem problemas, por outro lado com o segundo não.
Se necessário, posso fornecer mais registros ou resultados.

Meu Hardware:

Lenovo Y520
Intel I7 7700HQ (2,8 Ghz)
16 GB Ram
SSD Samsung 512 970Pro
WesternDigital WD10SPCX 1TB HDD
GPU Nvidia 1050TI de 4 GB

Meu software:

SO:
M $ Windows 10 - Versão 1903 - OsBuild 18917.1000

Código VS:
Versão: 1.36.0-insider (configuração do sistema)
Commit: 68a7e5bc437b38d0281df0756997a25da2a2900c
Data: 18/06/2019 T18: 40: 22.519Z
Elétron: 4.2.4
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-elétron.0
SO: Windows_NT x64 10.0.18917

PowerShell:
$ PSVersionTable

Valor do nome
---- -----
PSVersion 7.0.0-preview.1
PSEdition Core
GitCommitId 7.0.0-preview.1
SO Microsoft Windows 10.0.18917
Plataforma Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Cenários:

Cenário 1 :

Passos :
1-tente clicar com o botão direito em uma pasta e selecionar PowerShell preview 7 -> abrir aqui
Resultado:
funciona perfeitamente sem nenhum problema

Cenário 2:

Passos :
1-abra um VS Code em uma pasta pipenv (virtualenv) (clique com o botão direito em uma pasta / diretório e selecione Open with Code Insider)
2-espere até inicializar o virtualenv
3-tente clicar com o botão direito na mesma pasta e selecionar PowerShell preview 7 -> abrir aqui (ou tente executá-lo por meio de atalho)
Resultado:
Dá este erro e fecha:
Erro interno de CLR. (0x80131506)
em Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
em Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
em System.Threading.Tasks.Task.InnerInvoke ()
em System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
em System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
em System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
em System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
em System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
em System.Threading.ThreadPoolWorkQueue.Dispatch ()
em System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

@usta Você pode descrever o que quer dizer com 'pipenv (virtualenv)', eu não uso muito Python. Já que você diz que sempre pode reproduzir, por favor, leia meu comentário abaixo, instale a compilação personalizada e informe se ela corrige:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta Você pode descrever o que quer dizer com 'pipenv (virtualenv)', eu não uso muito Python. Já que você diz que sempre pode reproduzir, por favor, leia meu comentário abaixo, instale a compilação personalizada e informe se ela corrige:
# 9295 (comentário)
@bergmeister
Parece que este corrigiu o bug (se eu tiver encontrado o mesmo problema, irei mencioná-lo aqui), obrigado

Não consigo reproduzi-lo com o build personalizado, mas era muito raro com o 7 preview 1, mas o 6.2 faz isso muito regularmente. Pode haver alguma utilidade em aplicar um patch para uma versão personalizada do 6.2 ou uma série de versões do 6.2. Apenas adicionar debug / try / catch in pode ter mudado algo, como um bloqueio de recurso relacionado ao tempo ou algo assim.

cc @ TravisEz13 @adityapatwardhan , devemos considerar a mudança de @bergmeister para 6.2.2

@bergmeister podemos reabrir este bug, por favor?
Porque eu encontrei o mesmo bug hoje novamente (com o que você mencionou (a construção personalizada))
(ou talvez um diferente)

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

PS C: \ Windows \ System32> $ PSVersionTable

Valor do nome
---- -----
PSVersion 7.0.0-preview2.25651
PSEdition Core
GitCommitId 7.0.0-preview2.25651
SO Microsoft Windows 10.0.18922
Plataforma Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

@usta Sim, eu concordo, devemos reabrir (eu não tenho os direitos, mas irei notificar os mantenedores). Muito obrigado por relatar e fornecer o log, agora sabemos que o problema ocorre nesta linha (caso aconteça novamente, mas com um log diferente onde AddObject não é a última linha antes da falha, avise-nos embora ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonov Isso significa que, apesar dos relatórios positivos iniciais, o PR # 9928 não é capaz de detectar o erro CLR fatal que foi relatado várias vezes (todos os relatórios de bug relataram o mesmo erro). Embora ainda houvesse algum valor em fazer uma captura global para algo que não é essencial, o problema ainda persiste ... Com as informações adicionais, eu poderia tentar ver se podemos codificar de forma mais defensiva para evitar chegar a este ponto onde esta problema acontece (que eu suspeito ser um bug no próprio coreclr, vale a pena abrir um problema aí?). Caso contrário, só posso pensar em desativar esse recurso por meio de, por exemplo, uma variável de ambiente (ou armazenar algumas informações se o jumplist já tiver sido preenchido uma vez, visto que persiste depois, mas não tenho certeza se persiste após as atualizações do Windows ...) Deixe-me saber o que você pense / prefira.
Em uma nota relacionada, abri o seguinte problema e PR no WPF para adicionar as APIs necessárias para simplificar radicalmente o código / responsabilidade neste repo daqui para frente, mas até agora o PR não foi revisado e o problema foi marcado com .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister agora eu tentei repetidamente reproduzir o mesmo erro.
No final, posso reproduzi-lo, mas desta vez dá outro log:

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Comprometer
CoCreateInstance
AddObject
Exceção 'System.Runtime.InteropServices.InvalidComObjectException: O objeto COM que foi separado de seu RCW subjacente não pode ser usado.
em System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, sinalizadores Int32)
em Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
em Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (String title)
em Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () 'com rastreamento de pilha em System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, sinalizadores Int32)
em Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
em Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (String title)
em Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () capturado com sucesso.
PS C: \ Usuários \ usta>

Se necessário, terei o prazer de testar outra compilação ou tentar fornecer outros logs (que podem ser necessários para superar esse bug)

@bergmeister
Não sou nem mesmo $ programador de tecnologia, mas só por curiosidade essa linha também não precisa de uma verificação extra antes de passar para AddUserTasks?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87)
Quer dizer, não seria melhor algo assim:
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
if (hResult <0)
{
pShortCutCollection.Clear ();
Debug.Fail ($ "Não foi possível adicionar nativePropertyStore à coleção: HResult '{hResult}'.");
Retorna;
}

É possível detectar se a lista de atalhos já existe (persiste) e pular as etapas para criá-la nesse caso?

@usta não, AddObject é declarado como retornando void e, portanto, a camada de interoperabilidade fará a verificação (e lançará uma exceção)

@msftrncs Não conheço nenhuma API gerenciada que exponha a leitura de jumplists, então suspeito que a API nativa nem mesmo suporte isso, mas não verifiquei. De qualquer forma, apenas verificar a existência está errado, faria com que os jumplists ficassem desatualizados se uma de suas propriedades mudasse.

De qualquer forma, se você não puder resolver o problema aqui (e eu duvido seriamente que adicionar try / catch para um pânico de coreclr vá funcionar, nem é uma boa ideia), você provavelmente deve levantar um problema com coreclr para uma análise mais aprofundada. Afinal, você tem um depósito de lixo para examinar. O cenário no despejo certamente parece um bug de coreclr para mim. (Veja meu comentário acima para ver o que há de errado no lixo.)

Abri um problema com todos os detalhes no repositório CoreClr, talvez eles possam nos ajudar. Dei uma olhada no nosso código novamente e não há maneira mais defensiva de consultar uma API se o jumplist já tiver sido criado, só obtemos o número máximo de slots disponíveis disponíveis e já retornamos mais cedo se não houver espaço suficiente para o jumplist , tudo o que poderíamos fazer é armazenar em cache o jumplist internamente ou ter algo como um sinalizador de recurso para pular o código de criação do jumplist problemático (uma vez que a entrada do jumplist foi criada, ela persiste).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister Eu tentei a última compilação diária e parece que nesta compilação não consegui reproduzir o bug.
Se foi corrigido ou o motivo desse bug desapareceu.

PS C: \ Usuários \ usta> echo $ PSVersionTable

Valor do nome
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition Core
GitCommitId 7.0.0-dailypreview2.26796
SO Microsoft Windows 10.0.18922
Plataforma Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Todos: A equipe CoreClr investigou o problema e o problema é que as APIs COM que estão sendo chamadas são estritamente STA apenas (o PS Core ainda opera no MTA até que o número 7216 seja resolvido) e o coreclr não forneceu nenhum aviso / erro. Portanto, empurrei as alterações para criar a JumpList em um thread de STA, que deve ser a resolução final.
Teste novamente com a versão mais recente do PR # 9896 e forneça feedback

Todos: A correção para este problema foi retransmitida para o lançamento recente de 6.2.2 , atualize e forneça feedback se ela corrigiu. Os usuários da visualização terão que esperar por 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

: tada: Este problema foi resolvido em # 10057, que agora foi lançado com sucesso como v7.0.0-preview.2 .: tada:

Links úteis:

• Notas de Lançamento

: tada: Este problema foi resolvido em # 9928, que agora foi lançado com sucesso como v7.0.0-preview.2 .: tada:

Links úteis:

• Notas de Lançamento