Powershell: JumpList导致pwsh失败

创建于 2019-04-04  ·  62评论  ·  资料来源: PowerShell/PowerShell

从6.1.3升级到PowerShell 6.2，并删除PowerShell 6 Preview（6.2 RC 1）后，PowerShell通常将无法启动。 出现窗口，powershell看起来像它的开始，然后窗口关闭。 通常需要进行几次尝试才能使窗口成功进入提示。

所有更新/卸载过程都一次完成。 我有两台似乎显示此问题的机器，但我没有任何一台机器。

环境数据

Name                           Value
----                           -----
PSVersion                      6.2.0
PSEdition                      Core
GitCommitId                    6.2.0
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

我的另一台计算机正在运行最新的Windows 19H1 Insiders Preview。

在打开某些文档的同时，我在VS Code的PowerShell 2.0.1扩展中也遇到了很多崩溃，但是至少PowerShell 6.2通常可以在扩展的“集成控制台”中正常打开。 可能相关，也可能不相关，但是我也没有看到有人在该主题上发帖。

让我知道是否可以包含其他数据。

请注意，我最初在预览版本的早期更新方面遇到了麻烦，请参阅＃8442。 我没有检查那里的情况，因为在这种情况下，如果我继续尝试，PowerShell通常会打开。

Issue-Bug Resolution-Fixed WG-Engine
资料来源
picture msftrncs

最有用的评论

所有人：此问题的修复程序已移植到6.2.2的最新版本中，如果已解决，请进行更新并提供反馈。 预览版的用户必须等待7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

picture bergmeister 于 2019-07-16
👍2

所有62条评论

它可能与VS Code或VS Code上的PowerShell扩展有关。 重新启动系统后，我可以立即打开PowerShell，没有任何问题。 在VS Code打开的情况下，PowerShell的非管理会话拒绝保持打开状态。 即使关闭了VS Code，PowerShell似乎仍然拒绝可靠地打开。

msftrncs picture msftrncs 于 2019-04-04

您可以从cmd.exe运行PowerShell Core，然后看到错误消息。

iSazonov picture iSazonov 于 2019-04-05

当我尝试在提示符下从CMD打开PWSH时，PowerShell启动正常。 即使打开了该PowerShell会话，尝试从任务栏图标打开它也会导致它无法打开。 我还尝试在资源管理器地址栏中键入PWSH并获得相同的未打开结果。

如果不打开，就会发生这种情况。 弹出一个窗口，并显示标题信息：
```
PowerShell 6.2.0
版权所有（c）Microsoft Corporation。 版权所有。

https://aka.ms/pscore6-docs
键入“帮助”以获取帮助。
``
命令提示符从不出现，并且经过短暂的延迟后，窗口关闭。

如果我离开系统一段时间（几分钟，可能是10分钟，但是我确实继续在系统上执行其他任务），则打开PowerShell可以正常进行。 我已经能够重复这种模式。 在PowerShell正常打开后，我关闭了VS Code（如果它甚至已经打开），请稍等片刻，然后重新打开VS Code，再稍等片刻（可能是一分钟），然后PowerShell再次无法打开，并且在一段时间内再次保持打开状态。

昨晚我尝试在我的19H1内部人员机器上重复所有这些操作，并且第一次都不会重复。 首次打开PowerShell失败，但是即使重新启动后，以后每次也都可以使用。

msftrncs picture msftrncs 于 2019-04-05

当我尝试在提示符下从CMD打开PWSH时，

总是？

如果打开PowerShell Core主目录并双击pwsh.exe，它是否可以随时正常启动？

iSazonov picture iSazonov 于 2019-04-05

当我尝试在提示符下从CMD打开PWSH时，

总是？

至今。 我会尝试一个PWSH窗口，它将失败，我将打开CMD，键入PWSH，它开始正常，尝试另一个PWSH窗口，它将失败。 退出PWSH的CMD实例，然后重试，它将再次打开就好了。 我会重复一遍，完全关闭CMD窗口，重新开始，但CMD提示符下的PWSH似乎一直在工作。

而且，即使在PWSH窗口实例成功打开后，我也不会完全发誓，几分钟后再尝试一次，它将不会再次打开，没有任何特殊原因，到目前为止我无法推断出。

msftrncs picture msftrncs 于 2019-04-05

如果打开PowerShell Core主目录并双击pwsh.exe，它是否可以随时正常启动？

似乎是相同的不开放条件。 不过这很奇怪，因为直接单击EXE文件似乎在大多数情况下会导致相同的未打开状态，但是单击存储在开始菜单文件夹中的快捷方式似乎更为零星，通常可以成功打开，但绝对不是总是如此。

msftrncs picture msftrncs 于 2019-04-05

Windows操作系统为每个（控制台）应用程序保留一个窗口参数。 似乎参数已损坏，我们需要从注册表中清理它们。

iSazonov picture iSazonov 于 2019-04-05

我也在经历这个。 如果有帮助，则会在事件查看器中显示以下内容：

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 picture cpmcgrath 于 2019-04-15

就像@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:

我仍然看到这与使用PowerShell预览扩展打开VS代码相关，但是我想其他使用.Net的应用程序也可以设置此条件。

msftrncs picture msftrncs 于 2019-04-15

@msftrncs您能否编译并运行调试版本以获取更多信息？ 也很高兴从您那里获取回购步骤，以便我们可以在干净的系统上重现该问题。

iSazonov picture iSazonov 于 2019-04-16

我遇到了同样的问题。

来源：应用程序错误

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运行时

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错误报告收集的信息。
Report.zip

观察结果：

  • 我正在运行Windows v1903（操作系统内部版本18362.30）
  • 我确实安装了带有Powershell扩展（v2019.5.0）的Visual Studio Code（v1.35.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 picture Antaris 于 2019-06-11

@Antaris谢谢！ 您的回购是否持久？ 您可以回购最新的PowerShell Core版本吗？

iSazonov picture iSazonov 于 2019-06-11

它不是持久的，更断断续续的。 我将尝试下载最新的版本，看看是否可以解决。

Antaris picture Antaris 于 2019-06-11

@Antaris如果可以的话，请分叉

@ SteveL-MSFT我们应该担心6.2版本吗？

iSazonov picture iSazonov 于 2019-06-11

通过错误的模块名称判断，我感觉是.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 picture anmenaga 于 2019-06-11
👍1

@anmenaga

今天早上我设法触发了这种经历。 重新启动我的笔记本电脑。 第一次打开PowerShell Core很好。 然后，我使用Visual Studio Code读取了我的PS Core配置文件，并发起了一个保存操作，而没有做任何改动。 然后，我打开PowerShell Core，然后立即关闭。

转储文件在这里：
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov抱歉，我没有时间针对当前提交进行测试，我将在本周内尝试完成

Antaris picture Antaris 于 2019-06-12

似乎访问冲突来自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
anmenaga picture anmenaga 于 2019-06-12

这可以解释为什么如果我从命令行启动pwsh不会发生这种情况。

Antaris picture Antaris 于 2019-06-12

以前，我们曾看到过零星的故障报告，其他人则试图改善COM调用。 在这种情况下，我宁可怀疑使用的Windows Insider内部版本19H1也可能是罪魁祸首。
我使用相同的COM调用将原始C ++代码从Windows PowerShell移植到C＃，并将Windows Api包源代码用于COM接口定义。
好消息是，该代码仅在pwsh交互启动时才运行，并且跳转列表菜单注册仅需要发生一次（存在隐式检查代码的代码）。 也许我们应该在它周围放一个try {} catch块，只注销故障堆栈跟踪？
一般来说，当我这样做时，我必须将Windows Api Pack的完整.Net代码移植到.Net Core并对其进行调整，以允许具有提升的Jumpstart条目。 2周前，WPF添加了JumpList的源代码，并使用PR允许增加的跳转列表，我们可以将很多工作推迟到几行，但最终我认为这是一个.Net Core问题。

bergmeister picture bergmeister 于 2019-06-12

@bergmeister您愿意承担这项工作吗？ 请 ：）

SteveL-MSFT picture SteveL-MSFT 于 2019-06-12

我可以尝试，WPF API将需要一些类似的布尔参数（默认为false），以使跳转列表条目以提升模式打开应用程序。 这将取决于WPF成员愿意接受API更改的灵活性以及合并PR的难度，但是我认为这将与时间赛跑，因为.Net Core 3希望在7月左右发布RC。 （这意味着他们在那之后不太可能接受此类更改）...。
否则，唯一的选择就是尝试捕获该错误（但对我来说，这看起来像是不可捕获的致命CLR错误）。
我自己很不幸从未遇到过这样的错误

bergmeister picture bergmeister 于 2019-06-12

在GUI中似乎存在竞争状况。

@ SteveL-MSFT 6.2版本尚不清楚-我们也应该修复它吗？

iSazonov picture iSazonov 于 2019-06-13

没有任何数据来备份我的下一条语句，如果我使用“以管理员身份运行”打开PowerShell，似乎几乎不会发生此问题。

jlouros picture jlouros 于 2019-06-13
😄1

@jlouros我经历过非高架运行和以管理员身份运行

Antaris picture Antaris 于 2019-06-13

PS 7-preview1也会发生这种情况吗？ .Net Core 3改进了COM交互，这可能是.Net Core 2.1的问题。
另外：也许对类似于PR＃7580的代码进行类似的改进也可能会有所帮助？

bergmeister picture bergmeister 于 2019-06-13

@bergmeister ，我也曾在7预览版中遇到过这种情况，但这种情况发生的频率要少得多。 7预览版似乎提供了CLR错误转储，但是它关闭得如此之快……但是我明白了：

image

我也没有像@jlouros所提到的那样以“以管理员身份”运行时遇到这种情况，但是正如@Antaris所说，它仍然偶尔发生。

msftrncs picture msftrncs 于 2019-06-13

我们可以通过调试版本获得更多信息（我们将忽略代码中发布版本中的错误！）

iSazonov picture iSazonov 于 2019-06-13

@ SteveL-MSFT我在WPF中打开了一个API提议以首先获得批准（提议的更改是不间断的，因此应该可以），并包括一些底层实现细节。 我没有详细介绍WPF代码本身，但它应该不太困难（最困难的部分可能是测试）
https://github.com/dotnet/wpf/issues/950
这将是PowerShell 7的前进之路，当我开始更详细地阅读WPF代码时，我将尝试将其与实现进行比较，看看是否可以改进COM调用，我想知道这是否是一个问题AppartmentState是MTA因为我基本上将C ++ Windows PowerShell代码转换为C＃，并在最初执行实现时使用了Windows API中的接口定义

bergmeister picture bergmeister 于 2019-06-14

@bergmeister我现在认为，临时解决方案可能是将其包装在try ... catch中，以便至少启动pwsh。 我们可以将该修补程序用于6.2.x服务。 正确的修复程序可能会在以后出现。

SteveL-MSFT picture SteveL-MSFT 于 2019-06-14

@ SteveL-MSFT您确定可以捕获致命的CLR异常吗？ 由于我没有可以重现此环境的环境，因此很难验证此修复程序。 我可以尝试使用此修复程序构建PowerShell的一个版本，然后将其上传到此处，以便此问题的人对其进行测试？

bergmeister picture bergmeister 于 2019-06-14

@bergmeister我自己无法复制。 我认为最好的选择可能是您建议建立一个私有服务器，然后请可以复制它的人尝试一下。

SteveL-MSFT picture SteveL-MSFT 于 2019-06-14

我看到我们忽略了代码中可能是不好的返回码。

iSazonov picture iSazonov 于 2019-06-14

尽管[PreserveSig]属性在多个地方是错误的，但让PR修复它们时，我注意到它们只是在未调用的接口方法上是错误的。

如果您仍然想要PR，我可以在这里进行更改，但它不应该是崩溃的根源。

weltkante picture weltkante 于 2019-06-14

@weltkante有趣的是，我从原始Windows API包中获取了接口定义（请参见例如此处），却没有意识到这一点。 我不是这方面的专家，但是如果您认为自己的更改使它变得更好，请提交PR。

bergmeister picture bergmeister 于 2019-06-14

@Antaris @jlouros @msftrncs @cpmcgrath
在PR＃9896中，我添加了一个全局捕获，并添加了日志记录以获取更多信息。
请从该PR的PowerShell-CI-windows版本下载MSI。 如果您对系统不熟悉，请使用直接链接到此处的版本，然后单击右上角的按钮，然后单击Artifacts和artifacts子菜单。 这将下载一个zip文件，其中包含MSI，它是来自master中最新提交的PowerShell 7的自定义版本。
image

请报告它是否已解决，如果不能解决，请提供打印到PowerShell控制台的日志消息。 它将注销代码经过的所有阶段。 如果您看到格式Exception '{exception}' with stack trace {exception.StackTrace} successfully caught.的消息，请告知我们，因为这意味着catch语句能够捕获致命的CLR错误（我对此表示怀疑）。
这只是一个测试版本，并不打算用于任何受支持的用途。
更新（6月19日）：我将链接更新到了一个较新的版本，该链接应该在Task.Run语句内捕获异常，因为它仍然可能泄漏。

bergmeister picture bergmeister 于 2019-06-14

@bergmeister我已经安装了该Preview7 MSI，在我尝试重新创建该问题并将其作为我的主外壳运行几天后会回复您

Antaris picture Antaris 于 2019-06-14
👍2

我看到我们忽略了代码中可能是不好的返回码。

@iSazonov您在哪里看到的？ 我只是对COM接口声明以及调用CreateElevatedEntry方法进行了回顾，至少在实际使用的方法中，找不到任何明显错误的东西。 似乎所有声明PreserveSig的方法都在检查其返回码（方法返回void而未声明PreserveSig的方法由interop层检查）。

无论如何，不​​检查返回码不会导致coreclr中的AccessViolationException。 如果上面@anmenaga的stacktrace代表了该问题，那么很可能是coreclr互操作层中的另一个错误（已经有几个）

如果您的调查没有完成，那么值得让coreclr的人来看看转储。 内部coreclr代码中的stacktrace确实看起来不太像调用错误编码的interop声明。 特别是当在coreclr RCWHolder帮助器类中，对于中间的GetInteropInfoNoCreate调用m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount();返回NULL时，进行崩溃调用实际上并没有走多远。 （这就是转储中发生的事情，不知道其代表如何。）

weltkante picture weltkante 于 2019-06-14

我的意思是
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
在发布版本中，我们忽略失败结果。

iSazonov picture iSazonov 于 2019-06-14

@iSazonov啊，好吧，这并没有真正忽略失败结果，只是没有给出诊断信息。 它仍然立即返回，这意味着创建JumpList条目的尝试将被终止，而无需再进行任何COM调用。 回报当然不会导致我们在这里看到的那种崩溃。

weltkante picture weltkante 于 2019-06-14

我只是看了WPF的实现及其代码，检查它是否处于STA公寓状态。 WPF线程全部在STA中，所以我不确定此检查是否是由于WPF引起的，或者STA是否更适合我们进行的COM调用（由于.Net Core历来不支持，因此PowerShell Core甚至是7处于MTA模式） STA）：
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

bergmeister picture bergmeister 于 2019-06-14

通常，COM为您处理公寓，如果您不在STA上，则CoCreateInstance将为COM对象创建专用的STA线程，前提是它们被注册为仅在STA上运行。

由于.Net Core历来不支持STA，因此即使是7，PowerShell Core也处于MTA模式

您不能只将线程转给STA，如果这样做，那么您还需要一个消息循环。 如果您没有Windows消息循环，那么您可能不应该是STA。

weltkante picture weltkante 于 2019-06-14
👍1

@Antaris谢谢。 PS：如果您看到格式Exception '{exception}' with stack trace {exception.StackTrace} successfully caught.的消息，请告诉我们，因为这意味着catch语句能够捕获致命的CLR错误（我对此表示怀疑）。
同时，我怀疑此错误发生在具有不同硬件规格的计算机上，我对1、4和16个CPU内核感到厌倦。 任何人都可以分享详细信息吗？

bergmeister picture bergmeister 于 2019-06-14

@bergmeister我最近几天无法复制该问题。 我会继续这样做，因为我会不断使用PowerShell。

我也没有遇到任何例外。

供参考，我的规格机器是：
戴尔XPS 15 9570
英特尔酷睿i7-8750H-6核
32GB RAM

Antaris picture Antaris 于 2019-06-17

很好，但是您是否曾经在控制台中看到一条消息，内容如下：
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ？
仅当您看到它之后，它才可以证明致命CLR错误可以被成功捕获。

bergmeister picture bergmeister 于 2019-06-17

如果我尝试运行PowerShell，则每次都可以重现此错误。 我将在2个不同的场景中进行描述，在第一个场景中，它工作正常，而第二个场景则没有问题。
如果需要，我可以提供更多的日志或输出。

我的硬件：

联想Y520
英特尔I7 7700HQ（2.8Ghz）
16GB内存
三星512970Pro SSD
WesternDigital WD10SPCX 1TB硬盘
英伟达1050TI GPU 4GB

我的软件：

操作系统：
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-electron.0
作业系统：Windows_NT x64 10.0.18917

电源外壳：
$ PSVersionTable

名称值
---- -----
PSVersion 7.0.0-preview.1
PSEdition核心
GitCommitId 7.0.0-preview.1
操作系统Microsoft Windows 10.0.18917
平台Win32NT
PSCompatibleVersions {1.0、2.0、3.0、4.0 ...}
PSRemotingProtocolVersion 2.3
序列化版本1.1.0.1
WSManStackVersion 3.0

场景：

场景1：

脚步 ：
1-尝试右键单击一个文件夹，然后选择PowerShell预览7->在此处打开
结果：
完美运作，没有任何问题

方案2：

脚步 ：
1-在pipenv（virtualenv）文件夹中打开一个VS Code（右键单击一个文件夹/目录，然后选择“使用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 picture usta 于 2019-06-19

@usta请您描述一下'pipenv（virtualenv）'是什么意思，我不太使用Python。 由于您说自己可以随时复制，请阅读以下我的评论，安装自定义版本，并报告是否解决了该问题：
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

bergmeister picture bergmeister 于 2019-06-19

@usta请您描述一下'pipenv（virtualenv）'是什么意思，我不太使用Python。 由于您说自己可以随时复制，请阅读以下我的评论，安装自定义版本，并报告是否解决了该问题：
＃9295（评论）
@伯格梅斯特
看来这已解决了该错误（如果我遇到了同样的问题，我会在这里提及）。

usta picture usta 于 2019-06-20
👍2

我似乎无法通过自定义版本重现它，但是在7 Preview 1中很少见，但6.2却很定期。 将修补程序应用于6.2的自定义版本或6.2的一系列版本可能会有一些用处。 仅添加debug / try / catch可能会更改某些内容，例如与时间相关的资源锁定或其他内容。

msftrncs picture msftrncs 于 2019-06-20

cc @ TravisEz13 @adityapatwardhan我们应该考虑将@bergmeister更改为6.2.2

SteveL-MSFT picture SteveL-MSFT 于 2019-06-20
👍1

@bergmeister我们可以重新打开此错误吗？
因为我今天又遇到了相同的错误（与您提到的错误（自定义版本））
（或者可能是另一个）

GetStartupInfo
CoCreateInstance
BeginList
设定值
承诺
CoCreateInstance
添加对象
内部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

名称值
---- -----
PSVersion 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 ...}
PSRemotingProtocolVersion 2.3
序列化版本1.1.0.1
WSManStackVersion 3.0

usta picture usta 于 2019-06-25

@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更新后它是否仍然...）让我知道你想/喜欢。
在相关说明中，我在WPF中打开了以下问题，并在WPF中添加了PR，以添加所需的API，以从根本上简化此回购中的代码/职责，但到目前为止，PR尚未经过审核，并且已用.Net 5标记该问题
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

bergmeister picture bergmeister 于 2019-06-25

@bergmeister现在我一次又一次尝试重现相同的错误。
最后，我可能会重现它，但是这次它给出了另一个日志：

GetStartupInfo
CoCreateInstance
BeginList
设定值
承诺
CoCreateInstance
添加对象
异常'System.Runtime.InteropServices.InvalidComObjectException：无法使用与其基础RCW分离的COM对象。
在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（）'，在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：\ Users \ usta>

usta picture usta 于 2019-06-25
👍1

如果需要，我将很乐意测试另一个构建或尝试提供其他日志（可能需要克服此错误）

usta picture usta 于 2019-06-26

@伯格梅斯特
我什至不是技术程序员，但仅仅是出于好奇，在传递给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添加到Collection：HResult'{hResult}'。”）;
返回;
}

usta picture usta 于 2019-06-26

是否可以检测跳转列表是否已经存在（持久），并在这种情况下跳过构建该列表的步骤？

msftrncs picture msftrncs 于 2019-06-26

@usta不，AddObject被声明为返回void，因此互操作层将进行检查（并引发异常）

@msftrncs我不知道任何托管API公开读取

无论哪种方式，如果您不能在这里解决问题（并且我严重怀疑为coreclr恐慌添加try / catch不会起作用，也不是一个好主意），则可能应该向coreclr提出一个问题，以进行进一步检查。 毕竟您确实有一个转储要检查。 在我看来，转储中的场景肯定像是一个coreclr错误。 （请参阅上面我的

weltkante picture weltkante 于 2019-06-26
👍1

我打开了有关CoreClr存储库中所有详细信息的问题，也许它们可以为我们提供帮助。 我再次查看了我们的代码，如果已经创建了跳转列表，就没有更多防御性的查询API的方法，我们仅获得可用插槽的最大数量，如果跳转列表没有足够的空间，则早早返回，我们所能做的就是在内部缓存跳转列表，或者使用功能标记之类的东西跳过有问题的跳转列表创建代码（一旦创建了跳转列表条目，它就会持续存在）。
https://github.com/dotnet/coreclr/issues/25502

bergmeister picture bergmeister 于 2019-06-30

@bergmeister我尝试了最新的每日构建，但在此构建中，我无法重现该错误。
无论是固定的还是该错误的原因都没有。

PS C：\ Users \ usta> echo $ PSVersionTable

名称值
---- -----
PSVersion 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 ...}
PSRemotingProtocolVersion 2.3
序列化版本1.1.0.1
WSManStackVersion 3.0

usta picture usta 于 2019-07-02

所有人：CoreClr团队已调查了该问题，问题是被调用的COM API严格仅是STA（PS Core当前仍在MTA中运行，直到＃7216被解决），而coreclr没有提供任何警告/错误。 因此，我进行了一些更改，以在STA线程中创建JumpList，希望它应该是最终解决方案。
请使用最新版本的PR＃9896重新测试并提供反馈

bergmeister picture bergmeister 于 2019-07-03

所有人：此问题的修复程序已移植到6.2.2的最新版本中，如果已解决，请进行更新并提供反馈。 预览版的用户必须等待7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

bergmeister picture bergmeister 于 2019-07-16
👍2

： tada：此问题已在＃10057中得到解决，v7.0.0-preview.2 。：tada：

方便的链接：

msftbot[bot] picture msftbot[bot] 于 2019-07-17

： tada：此问题已在＃9928中解决，现已成功发布为v7.0.0-preview.2 。：tada：

方便的链接：

msftbot[bot] picture msftbot[bot] 于 2019-07-17
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

pcgeek86 picture pcgeek86  ·  3评论
HumanEquivalentUnit picture HumanEquivalentUnit  ·  3评论
mklement0 picture mklement0  ·  3评论
rudolfvesely picture rudolfvesely  ·  3评论
ajensenwaud picture ajensenwaud  ·  3评论