Puede estar relacionado con VS Code o la extensión de PowerShell en VS Code. Después de reiniciar mi sistema, pude abrir PowerShell inmediatamente sin problemas. Con VS Code abierto, las sesiones no administrativas de PowerShell se niegan a permanecer abiertas. Incluso después de cerrar VS Code, PowerShell parece negarse a abrir de manera confiable.

Puede ejecutar PowerShell Core desde cmd.exe y ver un mensaje de error.

Cuando trato de abrir PWSH desde CMD en el indicador, PowerShell comienza bien. Incluso con esa sesión de PowerShell abierta, intentar abrirla desde un icono de la barra de tareas hace que no se abra. También intenté escribir PWSH en la barra de direcciones de Explorer y obtuve el mismo resultado de no abrir.

Al no abrir, esto es lo que sucede. Aparecerá una ventana con la información del encabezado:
''
PowerShell 6.2.0
Copyright (c) Microsoft Corporation. Todos los derechos reservados.

https://aka.ms/pscore6-docs
Escriba 'ayuda' para obtener ayuda.
`` ``
El símbolo del sistema nunca aparece y, tras un breve retraso, la ventana se cierra.

Si dejo el sistema por un tiempo (minutos, tal vez 10 minutos, pero sigo haciendo otras tareas en el sistema), abrir PowerShell funciona bien. He podido repetir el patrón. Después de que PowerShell se abre bien, cierro VS Code (si incluso estaba abierto), espero un poco, vuelvo a abrir VS Code, espero un poco (tal vez un minuto) y luego PowerShell no se abre de nuevo, y esto permanece nuevamente por un período de tiempo .

Intenté repetir todo esto en mi máquina de insiders 19H1 anoche, y no se repetía más allá de la primera vez. La primera vez que se abrió PowerShell falló, pero las siguientes funcionó, incluso después de un reinicio.

Cuando intento abrir PWSH desde CMD en el indicador,

¿Siempre?

Si abre el directorio de inicio de PowerShell Core y hace doble clic en pwsh.exe, ¿comienza bien en algún momento?

Cuando intento abrir PWSH desde CMD en el indicador,

¿Siempre?

Hasta aquí. Probaría una ventana PWSH, fallaría, abriría CMD, escribiría PWSH, comenzó bien, probaría otra ventana PWSH, fallaría. SALGA de la instancia CMD de PWSH e intente nuevamente, se abriría bien nuevamente. Seguiría repitiendo, cerrando la ventana de CMD por completo, comenzando de nuevo, aún PWSH en un indicador de CMD parece estar siempre funcionando.

Además, no juro por completo que incluso después de que una instancia de una ventana de PWSH se abra con éxito, vuelva a intentarlo unos minutos más tarde y no se abrirá de nuevo, sin ninguna razón en particular que pueda deducir hasta ahora.

Si abre el directorio de inicio de PowerShell Core y hace doble clic en pwsh.exe, ¿comienza bien en algún momento?

Parece ser la misma condición de no apertura. Sin embargo, esto es extraño, porque hacer clic directamente en el archivo EXE parece resultar en la misma condición de no abrir la mayor parte del tiempo, pero hacer clic en el atajo almacenado en la carpeta del menú de inicio parece más esporádico, a menudo se abre con éxito, pero definitivamente no siempre .

El sistema operativo Windows mantiene una ventana de parámetros para cada aplicación (de consola). Parece que los parámetros están dañados y necesitamos limpiarlos del registro.

Yo también estoy experimentando esto. Si ayuda, aparece lo siguiente en el Visor 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: 

Al igual que @cpmcgrath , puedo confirmar que veo lo mismo en el registro de eventos de la aplicación inmediatamente después de un error al iniciar:
(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: 

Todavía veo esto relacionado con la apertura de VS Code con la extensión de vista previa de PowerShell, pero supongo que otras aplicaciones que usan .Net también podrían configurar esta condición.

@msftrncs ¿Podría compilar y ejecutar la compilación de depuración para obtener más información? También sería bueno que nos diera los pasos del repositorio para que podamos reproducir el problema en un sistema limpio.

Estoy experimentando este mismo problema.

Fuente: error de la aplicación

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: 

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

Adjunto la información recopilada por Windows Error Reporting.
Report.zip

Observaciones:

• Estoy ejecutando Windows v1903 (compilación del SO 18362.30)
• Tengo instalado Visual Studio Code (v1.35.0) con la extensión Powershell (v2019.5.0)
• Parece suceder después de un reinicio
• El tiempo de carga del perfil parece tardar un poco
• A veces sucede en el modo administrativo y otras veces no
• Tengo el módulo postgit instalado como parte de mi perfil, que se define a continuación:

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 ¡Gracias! ¿Su repositorio es persistente? ¿Puede realizar un repositorio con la última compilación de PowerShell Core?

No es persistente, más intermitente. Intentaré descargar la última versión y ver si eso lo soluciona.

@Antaris Si puede bifurcar el repositorio y compilar, con el modo de depuración podría obtener más información en excepción.

@ SteveL-MSFT ¿Deberíamos preocuparnos por la versión 6.2?

A juzgar por el nombre del módulo defectuoso, tengo la sensación de que es un problema de .NET. Algo similar sucedió antes.
Mientras tanto, aquí hay una forma sencilla de obtener un volcado del proceso de bloqueo con todos los detalles que ayudarán enormemente a investigar y corregir. @Antaris - puede probar la utilidad ProcDump :

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

La próxima vez que PS falle, el volcado con información detallada del error se escribirá en la carpeta especificada.

@anmenaga

Logré desencadenar esta experiencia esta mañana. Reinicio de mi computadora portátil. La primera vez que abrí PowerShell Core, estuvo bien. Luego utilicé Visual Studio Code para leer mi perfil de PS Core e inicié un guardado sin realizar modificaciones. Luego abrí PowerShell Core y se cerró de inmediato.

El archivo de volcado está aquí:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Lo siento, no he tenido tiempo de probar esto con el compromiso actual, intentaré hacerlo esta semana.

Parece que la infracción de acceso proviene de menos de TaskbarJumpList.CreateElevatedEntry .
@bergmeister , ¿recuerda algún problema de estabilidad con esta función?

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

Eso explicaría por qué esto no sucede si lanzo pwsh desde la línea de comando.

Hemos visto informes de fallas esporádicas antes y otras personas intentaron mejorar las llamadas COM. En este caso, sospecho que la compilación 19H1 de Windows Insider usada también podría ser un culpable.
Transferí el código C ++ original de Windows PowerShell a C # usando las mismas llamadas COM y usé el código fuente del paquete de Windows Api para las definiciones de la interfaz COM.
La buena noticia es que este código solo se ejecuta cuando pwsh se inicia de forma interactiva y que el registro del menú jumplist debe realizarse solo una vez (hay un código que lo verifica implícitamente). ¿Quizás deberíamos poner un bloque try {} catch alrededor y solo cerrar la sesión del seguimiento de la pila de fallas?
En términos generales, cuando lo hice, tuve que portar el código .Net completo del paquete Api de Windows a .Net Core y modificarlo para permitir una entrada de inicio rápido con elevación. Hace 2 semanas, WPF agregó el código fuente para JumpList y con un PR para permitir un jumplist elevado, podríamos posponer gran parte del trabajo a solo unas pocas líneas, pero en última instancia creo que es un problema de .Net Core.

@bergmeister ¿estás dispuesto a asumir este trabajo? Por favor :)

Puedo intentarlo, la API de WPF necesitará algo así como un parámetro booleano agregado (predeterminado en falso) para que la entrada jumplist abra la aplicación en modo elevado. Dependerá de cuán flexibles sean los chicos de WPF en términos de voluntad de aceptar el cambio de API y cuán difícil sea fusionar un PR, pero creo que será una carrera contra el tiempo porque .Net Core 3 quiere publicar un RC alrededor de julio (lo que significa que es menos probable que acepten tales cambios después de ese tiempo) ...
De lo contrario, la única alternativa sería intentar detectar el error (pero para mí esto parece un error de CLR fatal e irrecuperable).
Yo mismo, lamentablemente, nunca he experimentado tales errores.

Parece una condición de carrera en GUI.

@ SteveL-MSFT No está claro acerca de la versión 6.2, ¿deberíamos arreglarlo también?

Sin ningún dato para respaldar mi próxima declaración, parece que este problema casi nunca ocurre si abro PowerShell con 'Ejecutar como administrador'

@jlouros He experimentado tanto la ejecución no elevada como la ejecución como administrador

¿Sucede esto también con PS 7-preview1? .Net Core 3 ha mejorado la interacción COM, podría ser un problema de .Net Core 2.1.
Además: ¿Quizás una mejora similar al código similar al PR # 7580 también podría ayudar?

@bergmeister , también me ha pasado con la vista previa de 7, pero con mucha menos frecuencia. La vista previa de 7 parece dar un volcado de error CLR, pero se cierra tan rápido ... pero lo entendí:

Tampoco experimento esto tanto cuando ejecuto 'como administrador', como menciona @Antaris , todavía sucede ocasionalmente.

Podríamos obtener más información con la compilación de depuración (¡ignoramos los errores en la compilación de lanzamiento en el código!)

@ SteveL-MSFT Abrí una propuesta de API en WPF para obtener una aprobación primero (el cambio propuesto no es rotundo, por lo que debería estar bien) e incluí algunos detalles de implementación de bajo nivel. No he analizado el código WPF en sí en detalle, pero no debería ser demasiado difícil (la parte más difícil podría ser la prueba)
https://github.com/dotnet/wpf/issues/950
Este sería el camino a seguir para PowerShell 7, cuando empiece a leer el código WPF con más detalle, intentaré compararlo con mi implementación y ver si puedo mejorar las llamadas COM, me pregunto si esto es un problema del AppartmentState siendo MTA porque básicamente traduje el código C ++ de Windows PowerShell a C # y usé las definiciones de interfaz de la API de Windows cuando hice la implementación

@bergmeister Creo que por ahora, tal vez la solución provisional sea envolverlo en try ... catch para que pwsh al menos comience. Podemos llevar esa solución al servicio 6.2.x. La solución adecuada puede llegar más tarde.

@ SteveL-MSFT ¿Está seguro de que se puede detectar una excepción CLR fatal? Verificar la solución será difícil ya que no tengo un entorno donde pueda reproducir esto. ¿Podría intentar crear una versión de PowerShell con esta solución y cargarla aquí para que las personas en este problema la prueben?

@bergmeister No puedo

Veo que ignoramos los códigos de retorno en el código que pueden ser incorrectos.

[editar] ignore mi comentario anterior, aunque los atributos [PreserveSig] están incorrectos en varios lugares, mientras hacía el PR para solucionarlos, noté que solo estaban equivocados en los métodos de interfaz que no llamó.

Tengo los cambios aquí si quieres un PR de todos modos, pero no debería ser la fuente de los bloqueos.

@weltkante Interesante, tomé las definiciones de interfaz del paquete de API de Windows original (ver, por ejemplo, aquí ) y no estaba al tanto de esto. No soy un experto en esta área, pero si cree que sus cambios lo mejoran, envíe un PR.

@Antaris @jlouros @msftrncs @cpmcgrath
En PR # 9896, agregué una captura global a su alrededor y agregué registro para obtener más información.
Descargue el MSI de la compilación PowerShell-CI-windows de ese PR. Si no está familiarizado con el sistema, use el enlace directo a la compilación aquí y haga clic en el botón en la parte superior derecha, y luego haga clic en Artifacts y luego en el submenú artifacts . Esto le descargará un zip y allí está el MSI, que es una versión personalizada de PowerShell 7 de la última confirmación en master.

Informe si lo soluciona y, en caso contrario, proporcione los mensajes de registro que se imprimen en la consola de PowerShell. Se cerrará la sesión de todas las etapas por las que pasa el código. Si ve un mensaje con el formato Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. , háganoslo saber porque eso significaría que la declaración catch pudo detectar el error fatal de CLR (que dudo en este momento).
Esta es solo una versión de prueba y no está destinada a ningún uso compatible.
ACTUALIZACIÓN (19 de junio): Actualicé el enlace a una compilación más nueva que debería detectar las excepciones dentro de la declaración Task.Run , ya que antes aún podría haberse filtrado.

@bergmeister He instalado Preview7 MSI y me pondré en contacto con usted cuando intente recrear el problema y lo ejecute durante un par de días como mi shell principal 👍

Veo que ignoramos los códigos de retorno en el código que pueden ser incorrectos.

@iSazonov, ¿dónde ves eso? Acabo de revisar las declaraciones de la interfaz COM, así como el método de llamada CreateElevatedEntry y no pude encontrar nada obviamente incorrecto, al menos en los métodos que realmente se utilizan. Parece que todos los métodos que declaran PreserveSig están verificando sus códigos de retorno (los métodos que devuelven vacío y no declaran PreserveSig tienen su código de retorno verificado por la capa de interoperabilidad).

De todos modos, no verificar los códigos de retorno no puede llevar a AccessViolationException en coreclr. Si el stacktrace de @anmenaga anterior es representativo del problema, entonces podría ser otro error en la capa de interoperabilidad de coreclr (ya ha habido algunos)

Si su investigación no lleva a ninguna parte, podría valer la pena que alguien de coreclr eche un vistazo al vertedero. El stacktrace que está en el código coreclr interno realmente no se parece mucho a una llamada a declaraciones de interoperabilidad codificadas incorrectamente. En particular, cuando en la clase auxiliar de coreclr m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); devuelve NULL para la llamada intermedia de GetInteropInfoNoCreate entonces realmente no llegó muy lejos en la realización de la llamada bloqueada. (Esto es lo que sucedió en el basurero, ni idea de si su representante).

quiero decir
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
En la versión de versión ignoramos los resultados fallidos.

@iSazonov ah ok, esto realmente no ignora el resultado de la falla, simplemente no proporciona diagnósticos. Todavía regresa de inmediato, lo que significa que el intento de crear la entrada JumpList se cancela sin realizar más llamadas COM. Hacer una devolución ciertamente no puede conducir al tipo de caída que estamos viendo aquí.

Acabo de echar un vistazo a la implementación de WPF y su código verifica que esté en el estado del apartamento STA. Los subprocesos de WPF están todos en STA, por lo que no estoy seguro de si esta verificación se debe a WPF o si STA es más adecuado para las llamadas COM que hacemos (PowerShell Core, incluso 7, está en modo MTA debido a que .Net Core históricamente no es compatible STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

Por lo general, COM maneja el apartamento por usted, si no está en STA, entonces CoCreateInstance creará un hilo STA dedicado para los objetos COM si están registrados como que solo se ejecutan en STA.

PowerShell Core, incluso 7, está en modo MTA debido a que .Net Core históricamente no es compatible con STA

No puede simplemente convertir un hilo en STA, si lo hace, también necesita un bucle de mensaje. Si no tiene un bucle de mensajes de Windows, probablemente no debería ser STA.

@Antaris Gracias. PD: Si ve un mensaje con el formato Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. , háganoslo saber porque eso significaría que la declaración catch pudo detectar el error fatal de CLR (que dudo en este momento).
Mientras tanto, sospecho que este error ocurre más bien en máquinas de diferentes especificaciones de hardware, estoy cansado con 1, 4 y 16 núcleos de CPU. ¿Alguien puede compartir detalles?

@bergmeister No he podido replicar el problema en los últimos días. Seguiré así, ya que uso PowerShell constantemente.

Tampoco he encontrado ninguna excepción.

Como referencia, mi máquina de especificaciones es:
Dell XPS 15 9570
Intel Core i7-8750H - 6 núcleos
32 GB de RAM

Eso es bueno, pero ¿alguna vez ha visto un mensaje en la consola que dice algo como
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
Solo si lo ha visto, sería la prueba de que el error fatal de CLR podría detectarse con éxito.

Puedo reproducir este error cada vez que intento ejecutar PowerShell. Lo describiré en 2 escenarios diferentes, en el primero, está funcionando sin problemas, por otro lado, con el segundo no.
Si es necesario, puedo proporcionar más registros o salidas.

Mi hardware:

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

Mi software:

SO:
M $ Windows 10 - Versión 1903 - OsBuild 18917.1000

Código VS:
Versión: 1.36.0-insider (configuración del sistema)
Confirmar: 68a7e5bc437b38d0281df0756997a25da2a2900c
Fecha: 2019-06-18T18: 40: 22.519Z
Electrón: 4.2.4
Cromo: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
SO: Windows_NT x64 10.0.18917

Potencia Shell:
$ PSVersionTable

Valor de nombre
---- -----
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

Escenarios:

Escenario 1 :

Pasos:
1-intente hacer clic derecho en una carpeta y seleccione Vista previa de PowerShell 7 -> abrir aquí
Resultado:
funciona perfectamente sin ningún problema

Escenario 2:

Pasos:
1-abra un código VS en una carpeta pipenv (virtualenv) (haga clic con el botón derecho en una carpeta / directorio y seleccione Abrir con Code Insider)
2-espera hasta que se inicialice virtualenv
3-intente hacer clic derecho en la misma carpeta y seleccione Vista previa de PowerShell 7 -> abrir aquí (o intente ejecutarlo a través de un acceso directo)
Resultado:
Da este error y cierra:
Error de CLR interno. (0x80131506)
en Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
en Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
en System.Threading.Tasks.Task.InnerInvoke ()
en System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
en System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
en System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
en System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
en System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
en System.Threading.ThreadPoolWorkQueue.Dispatch ()
en System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

@usta ¿Puede describir lo que quiere decir con 'pipenv (virtualenv)'? No uso mucho Python. Como dice que siempre puede reproducir, lea mi comentario a continuación, instale la compilación personalizada e informe si lo soluciona:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta ¿Puede describir lo que quiere decir con 'pipenv (virtualenv)'? No uso mucho Python. Como dice que siempre puede reproducir, lea mi comentario a continuación, instale la compilación personalizada e informe si lo soluciona:
# 9295 (comentario)
@bergmeister
Parece que este ha solucionado ese error (si he tenido el mismo problema, lo mencionaré aquí) gracias

Parece que no puedo reproducirlo con la compilación personalizada, pero era bastante raro con 7 Preview 1, sin embargo, 6.2 lo hace con mucha regularidad. Puede resultar útil aplicar un parche a una compilación personalizada de 6.2 o una serie de compilaciones de 6.2. Simplemente agregando el debug / try / catch in podría haber cambiado algo, como el bloqueo de recursos relacionados con el tiempo o algo así.

cc @ TravisEz13 @adityapatwardhan deberíamos considerar llevar el cambio de @bergmeister a 6.2.2

@bergmeister, ¿podemos reabrir este error, por favor?
Porque volví a encontrar el mismo error hoy (con el que mencionaste (la compilación personalizada))
(o tal vez uno diferente)

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

PS C: \ Windows \ System32> $ PSVersionTable

Valor de nombre
---- -----
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 Sí, estoy de acuerdo, deberíamos volver a abrir (aunque no tengo los derechos, pero notificaré a los mantenedores). Muchas gracias por informar y proporcionar el registro, ahora sabemos que el problema ocurre en esta línea (en caso de que vuelva a ocurrir, pero con un registro diferente donde AddObject no es la última línea antes del bloqueo, avísenos ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonov Esto significa que, a pesar de los informes positivos iniciales, el PR # 9928 no puede detectar el error de CLR fatal que se ha informado varias veces (todos los informes de errores informaron el mismo error). Si bien todavía tenía cierto valor hacer una captura global para algo que no es esencial, el problema aún persiste ... Con la información adicional, podría intentar ver si podemos codificar de manera más defensiva para evitar llegar a este punto en el que esto ocurre un problema (que sospecho que es un error en el propio coreclr, ¿vale la pena abrir un problema allí?). De lo contrario, solo puedo pensar en deshabilitar esta función a través de, por ejemplo, una variable de entorno (o almacenar algo de información si el jumplist ya se ha llenado una vez, ya que persiste después, aunque no estoy seguro de si persiste después de las actualizaciones de Windows ...) pensar / preferir.
En una nota relacionada, abrí el siguiente problema y PR en WPF para agregar las API requeridas para simplificar radicalmente el código / responsabilidad en este repositorio en el futuro, pero hasta ahora el PR no se ha revisado y el problema se ha etiquetado con .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister ahora intenté una y otra vez reproducir el mismo error.
Al final puedo reproducirlo, pero esta vez da otro registro:

GetStartupInfo
CoCreateInstance
BeginList
Valor ajustado
Cometer
CoCreateInstance
AddObject
Excepción 'System.Runtime.InteropServices.InvalidComObjectException: el objeto COM que se ha separado de su RCW subyacente no se puede utilizar.
en System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, Int32 flags)
en Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
en Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (título de la cadena)
en Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () 'con seguimiento de pila en System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, marcas Int32)
en Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
en Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (título de la cadena)
en Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () capturado correctamente.
PS C: \ Usuarios \ usta>

Si es necesario, estaré encantado de probar otra compilación o intentar proporcionar otros registros (que podrían necesitar superar este error)

@bergmeister
Ni siquiera soy programador de $ technology, pero solo por curiosidad, ¿esta línea también necesita una verificación adicional antes de pasar a AddUserTasks?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87)
Quiero decir, ¿no sería mejor algo como esto?
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
si (hResult <0)
{
pShortCutCollection.Clear ();
Debug.Fail ($ "No se pudo agregar nativePropertyStore a la colección: HResult '{hResult}'.");
regreso;
}

¿Es posible detectar si la lista de salto ya existe (persiste) y omitir los pasos para construirla en ese caso?

@usta no, AddObject se declara que devuelve vacío y, por lo tanto, la capa de interoperabilidad hará la verificación (y lanzará una excepción)

@msftrncs No conozco ninguna API administrada que exponga la lectura de jumplists, por lo que sospecho que la API nativa ni siquiera la admite, pero no verifiqué. De cualquier manera, simplemente verificar la existencia es incorrecto, haría que los jumplistas se volvieran obsoletos si una de sus propiedades cambiara.

De cualquier manera, si no puede solucionar el problema aquí (y dudo seriamente que agregar try / catch para un pánico de coreclr no funcione ni sea una buena idea), probablemente debería plantear un problema con coreclr para un examen más detenido. Tienes un basurero para examinar después de todo. El escenario en el vertedero ciertamente me parece un error de coreclr. (Vea mi comentario anterior para saber qué sale mal en el vertedero).

Abrí un problema con todos los detalles en el repositorio de CoreClr, tal vez puedan ayudarnos. Eché un vistazo a nuestro código nuevamente y no hay forma más defensiva de consultar una API si el jumplist ya se ha creado, solo obtenemos el número máximo de ranuras disponibles disponibles y ya regresamos temprano si no hay suficiente espacio para el jumplist , todo lo que podemos hacer es almacenar en caché el jumplist internamente o tener algo como un indicador de función para omitir el código de creación del jumplist problemático (una vez que se ha creado la entrada jumplist, persiste).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister He probado la última compilación diaria y parece que en esta compilación no pude reproducir el error.
Ya sea que esté arreglado o que desaparezca el motivo de ese error.

PS C: \ Users \ usta> echo $ PSVersionTable

Valor de nombre
---- -----
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: El equipo de CoreClr ha investigado el problema y el problema es que las API COM que se están llamando son estrictamente solo STA (PS Core todavía opera en MTA hasta que se resuelva # 7216) y el coreclr no proporcionó ninguna advertencia / error. Por lo tanto, presioné cambios para crear JumpList en un hilo de STA, que con suerte debería ser la resolución final.
Vuelva a realizar la prueba con la última versión de PR # 9896 y envíe sus comentarios

Todos: la solución para este problema se ha actualizado a la versión reciente de 6.2.2 , actualice y envíe sus comentarios si se solucionó. Los usuarios de la vista previa deberán esperar 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

: tada: este problema se abordó en # 10057, que ahora se ha publicado con éxito como v7.0.0-preview.2 .: tada:

Enlaces útiles:

• Notas de lanzamiento

: tada: este problema se abordó en # 9928, que ahora se ha publicado con éxito como v7.0.0-preview.2 .: tada:

Enlaces útiles:

• Notas de lanzamiento