Это может быть связано с VS Code или расширением PowerShell в VS Code. После перезагрузки системы я смог сразу без проблем открыть PowerShell. При открытом VS Code неадминистративные сеансы PowerShell отказываются оставаться открытыми. Даже после закрытия VS Code PowerShell, похоже, отказывается надежно открываться.

Вы можете запустить PowerShell Core из cmd.exe и увидеть сообщение об ошибке.

Когда я пытаюсь открыть PWSH из CMD по запросу, PowerShell запускается нормально. Даже при открытом сеансе PowerShell попытка открыть его с помощью значка на панели задач приводит к тому, что он не открывается. Я также попытался ввести PWSH в адресной строке проводника и получить тот же результат без открытия.

Когда не открываешься, вот что происходит. Всплывает окно с информацией заголовка:
`` ''
PowerShell 6.2.0
Авторское право (c) Корпорация Microsoft. Все права защищены.

https://aka.ms/pscore6-docs
Введите "help", чтобы получить помощь.
`` ''
Командная строка никогда не появляется, а после небольшой задержки окно закрывается.

Если я выйду из системы на некоторое время (минут, может быть, 10 минут, но я продолжаю выполнять другие задачи в системе), тогда открытие PowerShell будет работать нормально. Мне удалось как бы повторить шаблон. После того, как PowerShell открывается нормально, я закрываю VS Code (если он даже был открыт), немного жду, снова открываю VS Code, подождите немного (возможно, минуту), а затем PowerShell снова не открывается, и это снова остается в течение некоторого периода времени. .

Я попытался повторить все это на своей машине инсайдеров 19H1 прошлой ночью, и в первый раз это не повторилось. Первый раз открыть PowerShell не удалось, но каждый последующий раз работал, даже после перезагрузки.

Когда я пытаюсь открыть PWSH из CMD по запросу,

Всегда?

Если вы откроете домашний каталог PowerShell Core и дважды щелкните pwsh.exe - будет ли он хорошо запускаться в любое время?

Когда я пытаюсь открыть PWSH из CMD по запросу,

Всегда?

Слишком далеко. Я бы попробовал открыть окно PWSH, ничего не получилось, я бы открыл CMD, набрал PWSH, он запустился нормально, попробовал другое окно PWSH, ничего не получилось. Выйдите из экземпляра CMD PWSH и повторите попытку, он снова откроется нормально. Я бы продолжал повторять, полностью закрывая окно CMD, начиная заново, но PWSH в приглашении CMD, кажется, всегда работает.

Кроме того, я не буду полностью клясться, что даже после того, как экземпляр окна PWSH успешно откроется, попытавшись снова через несколько минут, оно больше не откроется без какой-либо конкретной причины, которую я пока могу сделать.

Если вы откроете домашний каталог PowerShell Core и дважды щелкните pwsh.exe - будет ли он хорошо запускаться в любое время?

Вроде бы такое же закрытое состояние. Это странно, потому что непосредственный щелчок по EXE-файлу, кажется, в большинстве случаев приводит к одному и тому же условию запрета открытия, но нажатие на ярлык, хранящийся в папке меню «Пуск», кажется более спорадическим, часто открывается успешно, но определенно не всегда .

ОС Windows хранит параметры окна для каждого (консольного) приложения. Кажется, что параметры не работают, и нам нужно очистить их из реестра.

Я тоже это переживаю. Если это поможет, в средстве просмотра событий появится следующее:

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: 

Как и @cpmcgrath , я могу подтвердить, что вижу то же самое в журнале событий приложения сразу после неудачного запуска:
(2 мероприятия)

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: 

Я все еще вижу, что это связано с открытием VS Code с расширением PowerShell Preview Extension, но я полагаю, что другие приложения, использующие .Net, также могут установить это условие.

@msftrncs Не могли бы вы скомпилировать и запустить отладочную сборку, чтобы получить дополнительную информацию? Также было бы неплохо получить от вас шаги репо, чтобы мы могли воспроизвести проблему в чистой системе.

У меня такая же проблема.

Источник: Ошибка приложения

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: 

Источник: .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.

Я приложил информацию, собранную Windows Error Reporting.
Report.zip

Наблюдения:

• Я использую Windows v1903 (сборка ОС 18362.30)
• У меня установлен Visual Studio Code (v1.35.0) с расширением Powershell (v2019.5.0)
• Вроде бывает после перезагрузки
• Время загрузки профиля, похоже, занимает некоторое время
• Иногда это происходит в административном режиме, а иногда нет.
• У меня установлен модуль postgit как часть моего профиля, который определен ниже:

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 Спасибо! Ваше репо постоянно? Можете ли вы сделать репо с последней сборкой PowerShell Core?

Он не постоянный, более прерывистый. Я попробую скачать последнюю сборку и посмотрю, исправит ли это.

@Antaris Если вы можете разветвить репо и построить - в режиме отладки вы можете получить больше информации в исключении.

@ SteveL-MSFT Стоит ли беспокоиться о версии 6.2?

Судя по названию сбойного модуля, я чувствую, что это проблема .NET. Подобное происходило раньше.
Между тем, вот простой способ получить дамп процесса сбоя со всеми деталями, который очень поможет в расследовании и исправлении. @Antaris - вы можете попробовать утилиту ProcDump :

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

В следующий раз, когда PS выйдет из строя, дамп с подробной информацией об ошибке будет записан в указанную папку.

@anmenaga

Сегодня утром мне удалось вызвать это переживание. Свежий перезапуск моего ноутбука. Когда я впервые открыл PowerShell Core, все было нормально. Затем я использовал Visual Studio Code, чтобы прочитать свой профиль PS Core, и инициировал сохранение _ без внесения изменений_. Затем я открыл PowerShell Core, и он сразу закрылся.

Файл дампа находится здесь:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Извините, у меня не было времени проверить это с текущим коммитом, я постараюсь сделать это на этой неделе

Похоже, нарушение прав доступа исходит из-под TaskbarJumpList.CreateElevatedEntry .
@bergmeister , вы помните какие-либо проблемы со стабильностью работы этой функции?

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

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

Это объясняет, почему этого не происходит, если я запускаю pwsh из командной строки.

Мы и раньше видели сообщения о спорадических сбоях, и другие люди пытались улучшить COM-вызовы. В этом случае я скорее подозреваю, что использованная сборка Windows Insider 19H1 также может быть виновата.
Я перенес исходный код C ++ из Windows PowerShell на C #, используя те же вызовы COM, и использовал исходный код пакета Windows Api для определений интерфейса COM.
Хорошая новость заключается в том, что этот код запускается только тогда, когда pwsh запускается в интерактивном режиме, и что регистрация меню списка переходов должна происходить только один раз (есть код, который проверяет это неявно). Может быть, мы должны поместить вокруг него блок try {} catch и выйти только из трассировки стека ошибок?
Вообще говоря, когда я это сделал, мне пришлось перенести полный код .Net пакета Windows Api Pack на .Net Core и настроить его, чтобы разрешить переход с повышением прав. 2 недели назад WPF добавил исходный код для JumpList и с PR, чтобы разрешить расширенный список переходов, мы могли бы отложить большую часть работы всего на несколько строк, но в конечном итоге я думаю, что это проблема .Net Core.

@bergmeister , готовы ли вы взяться за эту работу? Пожалуйста :)

Я могу попробовать, WPF API понадобится что-то вроде добавленного логического параметра (по умолчанию false), чтобы запись jumplist открывала приложение в повышенном режиме. Это будет зависеть от того, насколько гибкими будут ребята из WPF с точки зрения готовности принять изменение API и насколько сложно будет объединить PR, но я думаю, что это будет гонка со временем, потому что .Net Core 3 хочет опубликовать RC примерно в июле. (это означает, что они с меньшей вероятностью примут такие изменения после этого времени) ....
В противном случае единственной альтернативой было бы попытаться отловить ошибку (но для меня это выглядит как неуловимая фатальная ошибка CLR).
Сам я таких ошибок, к сожалению, не встречал

Это похоже на состояние гонки в графическом интерфейсе.

@ SteveL-MSFT Непонятно, как обстоят дела с версией 6.2 - стоит ли ее тоже исправлять?

Без каких-либо данных для резервного копирования моего следующего утверждения кажется, что эта проблема почти никогда не возникает, если я открываю PowerShell с помощью «Запуск от имени администратора».

@jlouros Я испытал как работу без повышенных

Это происходит и с PS 7-preview1? .Net Core 3 улучшил взаимодействие с COM, это может быть проблемой .Net Core 2.1.
Также: Может быть, подобное улучшение кода, похожее на PR # 7580, тоже может помочь?

@bergmeister , у меня с 7 превью тоже бывало, но гораздо реже. 7 предварительный просмотр, кажется, дает дамп ошибки CLR, но он закрывается так быстро ... но я понял:

Я также не испытываю этого почти так часто, когда запускаю «от имени администратора», как упоминает @jlouros , но, как сказал @Antaris , это все еще иногда случается.

Мы могли бы получить больше информации с помощью сборки отладки (мы игнорируем ошибки сборки выпуска в коде!)

@ SteveL-MSFT Я открыл предложение API в WPF, чтобы сначала получить подтверждение (предлагаемое изменение не является критическим, поэтому оно должно быть в порядке) и включил некоторые детали реализации на низком уровне. Я не рассматривал сам код WPF подробно, но это не должно быть слишком сложно (самой сложной частью может быть тестирование)
https://github.com/dotnet/wpf/issues/950
Это был бы путь вперед для PowerShell 7, поскольку я начинаю читать код WPF более подробно, я попытаюсь сравнить его с моей реализацией и посмотреть, смогу ли я улучшить вызовы COM, мне интересно, является ли это проблемой AppartmentState является MTA потому что я в основном перевел код C ++ Windows PowerShell на C # и использовал определения интерфейса из Windows API, когда я изначально делал реализацию

@bergmeister На данный момент я думаю, что временное решение - обернуть его в try ... catch, чтобы хотя бы запускался pwsh. Мы можем внести это исправление в обслуживание 6.2.x. Правильное исправление может появиться позже.

@ SteveL-MSFT Вы уверены, что фатальное исключение CLR может быть обнаружено? Проверить исправление будет сложно, поскольку у меня нет среды, в которой я мог бы воспроизвести это. Я мог бы попробовать собрать версию PowerShell с этим исправлением и загрузить ее сюда, чтобы люди, столкнувшиеся с этой проблемой, ее протестировали?

@bergmeister Я не могу

Я вижу, что мы игнорируем коды возврата в коде, который может быть плохим.

[править] не обращайте внимания на мой предыдущий комментарий, хотя атрибуты [PreserveSig] неверны в нескольких местах, при создании PR для их исправления я заметил, что они ошибались только в методах интерфейса, которые вы не вызывали.

У меня есть изменения здесь, если вы все равно хотите PR, но он не должен быть источником сбоев.

@weltkante Интересно, что я взял определения интерфейса из исходного пакета Windows API (см., например, здесь ) и не знал об этом. Я не эксперт в этой области, но если вы считаете, что ваши изменения улучшат ситуацию, отправьте PR.

@Antaris @jlouros @msftrncs @cpmcgrath
В PR # 9896 я добавил глобальную уловку и добавил логирование, чтобы получить больше информации.
Загрузите MSI из сборки PowerShell-CI-windows этого PR. Если вы не знакомы с системой, просто используйте прямую ссылку на сборку здесь и нажмите кнопку в правом верхнем углу, а затем нажмите Artifacts а затем подменю artifacts . Это загрузит вам zip-архив и там будет MSI, который представляет собой настраиваемую версию PowerShell 7 из последней фиксации в master.

Сообщите, исправляет ли он это, а если нет, предоставьте сообщения журнала, которые будут распечатаны в консоли PowerShell. Он завершит все этапы, через которые проходит код. Если вы видите сообщение в формате Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. сообщите нам об этом, потому что это будет означать, что оператор catch смог перехватить фатальную ошибку CLR (в которой я сомневаюсь на данный момент).
Это просто тестовая сборка и не предназначена для поддерживаемого использования.
ОБНОВЛЕНИЕ (19 июня): я обновил ссылку на более новую сборку, которая должна перехватывать исключения внутри оператора Task.Run как и раньше, когда он мог просочиться.

@bergmeister Я установил этот MSI Preview7 и вернусь к вам, когда попытаюсь воссоздать проблему и запустить ее на пару дней в качестве основной оболочки 👍

Я вижу, что мы игнорируем коды возврата в коде, который может быть плохим.

@iSazonov где ты это видишь? Я только что просмотрел объявления интерфейса COM, а также вызывающий метод CreateElevatedEntry и не нашел ничего явно неправильного, по крайней мере, в методах, которые фактически используются. Похоже, что все методы, объявляющие PreserveSig, проверяют свои коды возврата (методы, возвращающие void и не объявляющие PreserveSig, имеют свой код возврата, проверенный уровнем взаимодействия).

В любом случае, отсутствие проверки кодов возврата не может привести к исключению AccessViolationException в coreclr. Если трассировка стека из @anmenaga выше представляет проблему, то это вполне может быть еще одна ошибка в уровне взаимодействия coreclr (их уже было несколько)

Если ваше расследование ни к чему не приведет, возможно, стоит попросить кого-нибудь из coreclr взглянуть на дамп. Трассировка стека, находящаяся во внутреннем коде coreclr, действительно не очень похожа на вызов неверно закодированных объявлений взаимодействия. В частности, когда во вспомогательном классе coreclr m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); возвращает NULL для среднего вызова GetInteropInfoNoCreate тогда на самом деле он не очень далеко продвинулся при выполнении аварийного вызова. (Вот что произошло на свалке, не знаю, был ли его представитель.)

я имею в виду
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
В сборке релиза мы игнорируем неудачные результаты.

@iSazonov а, ладно, это не игнорирует результат сбоя, просто не выдает диагностику. Он по-прежнему немедленно возвращается, что означает, что попытка создания записи JumpList прерывается без выполнения дополнительных вызовов COM. Возврат, конечно же, не может привести к той аварии, которую мы здесь наблюдаем.

Я только что взглянул на реализацию WPF, и его код проверяет, находится ли он в состоянии квартиры STA. Все потоки WPF находятся в STA, поэтому я не уверен, связана ли эта проверка с WPF или STA больше подходит для выполняемых нами вызовов COM (PowerShell Core, даже 7, находится в режиме MTA из-за того, что .Net Core исторически не поддерживает STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

Обычно COM обрабатывает квартиру за вас, если вы не на STA, тогда CoCreateInstance создаст выделенный поток STA для COM-объектов, если они зарегистрированы как работающие только на STA.

PowerShell Core, даже 7, находится в режиме MTA из-за того, что .Net Core исторически не поддерживает STA

Вы не можете просто превратить поток в STA, если вы это сделаете, вам также понадобится цикл сообщений. Если у вас нет цикла сообщений Windows, вам, вероятно, не стоит быть STA.

@Antaris Спасибо. PS: Если вы видите сообщение в формате Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. сообщите нам, потому что это будет означать, что оператор catch смог отловить фатальную ошибку CLR (в которой я сомневаюсь на данный момент).
Тем временем я подозреваю, что эта ошибка возникает скорее на машинах с разной аппаратной спецификацией, я устал с 1, 4 и 16 ядрами процессора. Может кто-нибудь поделится подробностями?

@bergmeister Я не мог воспроизвести проблему в последние несколько дней. Я буду продолжать, поскольку постоянно использую PowerShell.

Я тоже не встречал исключений.

Для справки, моя машина со спецификациями:
Dell XPS 15 9570
Intel Core i7-8750H - 6 ядер
32 ГБ RAM

Это хорошо, но видели ли вы когда-нибудь в консоли сообщение вроде
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
Только если вы это видели, это будет доказательством того, что фатальная ошибка CLR может быть успешно обнаружена.

Я могу воспроизводить эту ошибку каждый раз, если попытаюсь запустить PowerShell. Я опишу в двух разных сценариях, в первом он работает без проблем, а во втором - нет.
При необходимости я могу предоставить больше журналов или результатов.

Мое оборудование:

Lenovo Y520
Intel I7 7700HQ (2,8 ГГц)
16 ГБ ОЗУ
SSD-накопитель Samsung 512 970Pro
WesternDigital WD10SPCX 1 ТБ HDD
Графический процессор Nvidia 1050TI, 4 ГБ

Мое программное обеспечение:

ОПЕРАЦИОННЫЕ СИСТЕМЫ :
M $ Windows 10 - версия 1903 - OsBuild 18917.1000

Код VS:
Версия: 1.36.0-insider (настройка системы)
Фиксация: 68a7e5bc437b38d0281df0756997a25da2a2900c
Дата: 2019-06-18T18: 40: 22.519Z
Электрон: 4.2.4
Хром: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-электрон.0
ОС: Windows_NT x64 10.0.18917

PowerShell:
$ PSVersionTable

Имя Значение
---- -----
PS Версия 7.0.0-превью.1
Ядро PSEdition
GitCommitId 7.0.0-preview.1
ОС Microsoft Windows 10.0.18917
Платформа Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolВерсия 2.3
Сериализация Версия 1.1.0.1
WSManStackVersion 3.0

Сценарии:

Сценарий 1:

Шаги:
1-попробуйте щелкнуть папку правой кнопкой мыши и выбрать предварительный просмотр PowerShell 7 -> открыть здесь
Результат:
отлично работает без проблем

Сценарий 2:

Шаги:
1-откройте VS Code в папке pipenv (virtualenv) (щелкните правой кнопкой мыши папку / каталог и выберите Открыть с помощью Code Insider)
2-подождите, пока он инициализирует virtualenv
3-попробуйте щелкнуть правой кнопкой мыши ту же папку и выбрать предварительный просмотр PowerShell 7 -> открыть здесь (или попробуйте запустить его с помощью ярлыка)
Результат:
Выдает эту ошибку и закрывает:
Внутренняя ошибка среды CLR. (0x80131506)
в Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
в 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 Не могли бы вы описать, что вы имеете в виду под «pipenv (virtualenv)», я не очень часто использую Python. Поскольку вы говорите, что всегда можете воспроизвести, прочтите мой комментарий ниже, установите пользовательскую сборку и сообщите, исправляет ли она это:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta Не могли бы вы описать, что вы имеете в виду под «pipenv (virtualenv)», я не очень часто использую Python. Поскольку вы говорите, что всегда можете воспроизвести, прочтите мой комментарий ниже, установите пользовательскую сборку и сообщите, исправляет ли она это:
# 9295 (комментарий)
@bergmeister
Похоже, этот исправил эту ошибку (если я столкнулся с той же проблемой, я упомяну об этом здесь), спасибо

Кажется, я не могу воспроизвести это с помощью пользовательской сборки, но это было довольно редко с предварительным просмотром 7 1, но 6.2 делает это очень регулярно. Может быть некоторая полезность в применении патча к пользовательской сборке версии 6.2 или к серии сборок версии 6.2. Простое добавление debug / try / catch могло что-то изменить, например, блокировку ресурсов, связанную с временем, или что-то в этом роде.

cc @ TravisEz13 @adityapatwardhan мы должны рассмотреть возможность изменения

@bergmeister, мы можем снова открыть эту ошибку?
Потому что сегодня я снова столкнулся с той же ошибкой (с той, которую вы упомянули (пользовательская сборка))
(или, может быть, другой)

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Зафиксировать
CoCreateInstance
AddObject
Внутренняя ошибка среды CLR. (0x80131506)
в Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
в 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

Имя Значение
---- -----
PS Версия 7.0.0-превью2.25651
Ядро PSEdition
GitCommitId 7.0.0-preview2.25651
ОС Microsoft Windows 10.0.18922
Платформа Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolВерсия 2.3
Сериализация Версия 1.1.0.1
WSManStackVersion 3.0

@usta Да, я согласен, мы должны снова открыть (хотя у меня нет прав, но я уведомлю сопровождающих). Большое спасибо за сообщение и предоставление журнала, теперь мы знаем, что проблема возникает в этой строке (если это произойдет снова, но с другим журналом, где AddObject - не последняя строка перед аварией, сообщите нам об этом ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonov Это означает, что, несмотря на первоначальные положительные сообщения, PR # 9928 не может отловить фатальную ошибку CLR, о которой сообщалось несколько раз (все отчеты об ошибках сообщали об одной и той же ошибке). Хотя было еще некоторая ценность в том, чтобы сделать глобальный улов для чего-то несущественного, проблема все еще сохраняется ... С дополнительной информацией я мог бы попытаться выяснить, можем ли мы кодировать более защитно, чтобы не добраться до этой точки, где это возникает проблема (я подозреваю, что это ошибка в самом coreclr, стоит ли открывать там проблему?). В противном случае я могу думать только об отключении этой функции, например, с помощью переменной среды (или сохранения некоторой информации, если список переходов уже был заполнен один раз, поскольку он сохраняется после этого, хотя не уверен, сохраняется ли он после обновлений Windows ...) Дайте мне знать, что вы думаю / предпочитаю.
В связи с этим я открыл следующую проблему и PR в WPF, чтобы добавить необходимые API, чтобы радикально упростить код / ​​ответственность в этом репо в будущем, но пока PR не был рассмотрен, и проблема была помечена с помощью .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister теперь я снова и снова пытался воспроизвести ту же ошибку.
В конце я могу воспроизвести его, но на этот раз он даст другой журнал:

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Зафиксировать
CoCreateInstance
AddObject
Exception 'System.Runtime.InteropServices.InvalidComObjectException: COM-объект, который был отделен от его основного RCW, использовать нельзя.
в System.StubHelpers.InterfaceMarshaler.ConvertToNative (объект objSrc, IntPtr itfMT, IntPtr classMT, флаги Int32)
в Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
в Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (заголовок строки)
в Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () 'с трассировкой стека в System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, флаги Int32)
в Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
в Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (заголовок строки)
в Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () успешно пойман.
PS C: \ Пользователи \ уста>

При необходимости я буду рад протестировать другую сборку или попытаться предоставить другие журналы (которые могут потребоваться для устранения этой ошибки)

@bergmeister
Я даже не являюсь программистом в области технологий, но только из любопытства, разве эта строка также не требует дополнительной проверки перед переходом к AddUserTasks?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87)
Я имею в виду, что может быть лучше что-то вроде этого:
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
если (hResult <0)
{
pShortCutCollection.Clear ();
Debug.Fail ($ "Не удалось добавить nativePropertyStore в коллекцию: HResult '{hResult}'.");
возвращение;
}

Можно ли определить, существует ли список переходов (сохраняется), и пропустить шаги по его созданию в этом случае?

@usta нет, AddObject объявлен как возвращающий void, и поэтому уровень взаимодействия выполнит проверку (и выдаст исключение)

@msftrncs Я не знаю ни одного управляемого API, открывающего чтение списков переходов, поэтому я подозреваю, что собственный API даже не поддерживает его, но я не проверял. В любом случае, просто проверка существования неверна, это приведет к устареванию списков переходов, если одно из их свойств изменится.

В любом случае, если вы не можете решить проблему здесь (и я серьезно сомневаюсь, что добавление try / catch для паники coreclr сработает и не является хорошей идеей), вам, вероятно, следует поднять проблему с coreclr для дальнейшего изучения. В конце концов, вам нужно изучить дамп. Сценарий в дампе определенно выглядит для меня ошибкой coreclr. (См. Мой комментарий выше, чтобы узнать, что не так в дампе.)

Я открыл проблему со всеми подробностями в репозитории CoreClr, может, они нам помогут. Я снова взглянул на наш код, и нет более защитного способа запроса API, если список переходов уже был создан, мы получаем только максимальное количество доступных доступных слотов и уже возвращаемся раньше, если недостаточно места для списка переходов , все, что мы могли сделать, это кэшировать список переходов внутри или иметь что-то вроде флага функции, чтобы пропустить проблемный код создания списка переходов (после создания записи списка переходов он сохраняется).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister Я пробовал последнюю ежедневную сборку, и похоже, что в этой сборке мне не удалось воспроизвести ошибку.
Исправлена ​​ли она или исчезла причина этой ошибки.

PS C: \ Users \ usta> echo $ PSVersionTable

Имя Значение
---- -----
PS Версия 7.0.0-dailypreview2.26796
Ядро PSEdition
GitCommitId 7.0.0-dailypreview2.26796
ОС Microsoft Windows 10.0.18922
Платформа Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolВерсия 2.3
Сериализация Версия 1.1.0.1
WSManStackVersion 3.0

Все: команда CoreClr исследовала проблему, и проблема в том, что вызываемые API-интерфейсы COM являются строго только STA (PS Core в настоящее время все еще работает в MTA до устранения # 7216), а coreclr не выдавал никаких предупреждений / ошибок. Поэтому я внес изменения, чтобы создать список JumpList в потоке STA, который, надеюсь, станет окончательным решением.
Пожалуйста, повторите тест с последней сборкой PR # 9896 и оставьте отзыв

Для всех: исправление этой проблемы было перенесено в недавний выпуск 6.2.2 Пожалуйста, обновите и оставьте отзыв, если он исправил. Пользователям превью придется ждать 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

: tada: Эта проблема устранена в # 10057, который теперь успешно выпущен как v7.0.0-preview.2 .: tada:

Полезные ссылки:

• Примечания к выпуску

: tada: Эта проблема устранена в # 9928, который теперь успешно выпущен как v7.0.0-preview.2 .: tada:

Полезные ссылки:

• Примечания к выпуску