It may be related to VS Code or the PowerShell extension on VS Code. After rebooting my system, I was able to immediately open PowerShell with no issue. With VS Code open, non-administrative sessions of PowerShell refuse to stay open. Even after closing VS Code, PowerShell seems to refuse reliably opening.

You could run PowerShell Core from cmd.exe and see an error message.

When I try to open PWSH from CMD at prompt, PowerShell starts fine. Even with that session of PowerShell open, attempting to open it from a taskbar icon results in it not opening. I also tried typing PWSH in an Explorer address bar and get same no-open result.

By not opening, this is what happens. A window pops up, and has the header info:
```
PowerShell 6.2.0
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/pscore6-docs
Type 'help' to get help.
````
The command prompt never appears, and after a short delay, the window closes.

If I leave the system for a while (minutes, maybe 10 minutes, but I do continue doing other tasks on the system) then opening PowerShell works fine. I've been able to kind of repeat the pattern. After PowerShell is opening fine, I close VS Code (if it was even open), wait a bit, reopen VS Code, wait a bit (maybe a minute) and then PowerShell fails opening again, and this remains again for some period of time.

I tried repeating all this on my 19H1 insiders machine last night, and it would not repeat past the first time. The first time opening PowerShell failed, but every subsequent time worked, even after a reboot.

When I try to open PWSH from CMD at prompt,

Always?

If you open PowerShell Core home directory and double click on pwsh.exe - does it start well in any time?

When I try to open PWSH from CMD at prompt,

Always?

So far. I would try a PWSH window, it would fail, I would open CMD, type PWSH, it started fine, try another PWSH window, it would fail. EXIT the CMD instance of PWSH and try again, it would open just fine again. I'd keep repeating, closing CMD window entirely, starting over, still PWSH at a CMD prompt seems to be always working.

Also, I will not completely swear, that even after an instance of a PWSH window successfully opens, attempting again a few minutes later and it won't open again, without any particular reason I can so far deduce.

If you open PowerShell Core home directory and double click on pwsh.exe - does it start well in any time?

It seems to be the same no-open condition. This is weird though, because directly clicking on EXE file seems to result in the same no-open condition most the time, but clicking on the short-cut stored in the start menu folder seems more sporadic, often opening successfully, but definitely not always.

Windows OS keeps a window parameters for every (console) application. It seems the parameters is broken and we need clean up them from registry.

I'm experiencing this too. If it helps, the following appears in the Event Viewer:

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: 

Just like @cpmcgrath, I can confirm that I see the same thing in the application event log immediately after a failure to launch:
(2 events)

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: 

I am still seeing this corelated to opening VS Code with the PowerShell Preview Extension, but I suppose other applications that use .Net could set up this condition as well.

@msftrncs Could you please compile and run debug build to get more info? Also it would be nice to get repo steps from you so that we can reproduce the problem on clean system.

I am experiencing this same issue.

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: 0x4e64
Faulting application start time: 0x01d520380945a490
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 0fe828fd-a45e-4dc2-b7f0-77b07ecdba93
Faulting package full name: 
Faulting package-relative application ID: 

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

I've attached the information collected by Windows Error Reporting.
Report.zip

Observations:

• I am running Windows v1903 (OS Build 18362.30)
• I do have Visual Studio Code installed (v1.35.0) with the Powershell extension (v2019.5.0)
• It seems to happen after a reboot
• Profile load time does seem to take a while
• It sometimes happens in Adminsitrative mode, and sometimes not
• I have the postgit module installed as part of my profile, which is defined below:

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 Thanks! Is your repo persistent? Can you repo with latest PowerShell Core build?

It is not persistent, more intermittent. I'll try and download the latest build and see if that fixes it.

@Antaris If you can please fork the repo and build - with debug mode you could get more information in exception.

@SteveL-MSFT Should we be worried about 6.2 version?

Judging by faulting module name I have a feeling that is .NET problem. Similar thing happened before.
Meanwhile, here is a simple way to get a dump of the crashing process with all details that will help greatly to investigate and fix. @Antaris - you can try ProcDump utility:

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

The next time PS crashes, the dump with detailed error info will be written to the specified folder.

@anmenaga

I managed to trigger this experience this morning. Fresh re-start of my laptop. The first time I opened PowerShell Core, it was fine. I then used Visual Studio Code to read my PS Core profile, and initiated a save _without making alterations_. I then opened PowerShell Core and it immediately closed.

Dump file is here:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Sorry, I haven't had time to test this against the current commit, I'll try and get that done this week

It looks like the Access violation is coming from under TaskbarJumpList.CreateElevatedEntry.
@bergmeister , do you recall any stability issues with this function?

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

That would explain why this doesnt happen if I launch pwsh from the command line.

We have seen reports of sporadic failures of it before and other people tried to improve the COM calls. In this case I rather suspect that the used Windows Insider build 19H1 might be a culprit as well.
I ported the original C++ code from Windows PowerShell to C# using the same COM calls and used the Windows Api pack source code for the COM interface definitions.
The good news is that this code only runs when pwsh starts interactively and that the jumplist menu registration needs to happen only once (there is code that checks that implicitly). Maybe we should put a try{}catch block around it and only log out the failure stack trace?
Generally speaking, when I did it I had to port the full .Net code of the Windows Api Pack to .Net Core and tweak it to allow for a jumpstart entry with elevation. 2 weeks ago, WPF added the source code for JumpList and with a PR to allow for an elevated jumplist we could defer a lot of the work to just a few lines, but ultimately I think it is a .Net Core problem.

@bergmeister are you willing to take on this work? Please :)

I can try, the WPF API will need something like an added boolean parameter (defaulting to false) to make the jumplist entry open the application in elevated mode. It will depend on how flexible the WPF guys are in terms of willing to accept the API change and how hard it is to get a PR merged but I think it will be race against time because .Net Core 3 wants to publish an RC around July (meaning that they are less likely to accept such changes after that time)....
Otherwise the only alternative would be to try to catch the error (but to me this looks like an uncatchable, fatal CLR error).
I myself have unfortunately never experienced such errors

It seems a race condition in GUI.

@SteveL-MSFT It is not clear about 6.2 version - should we fix it too ?

Without any data to back up my next statement, it seems this issue almost never happens if I open PowerShell with 'Run as Administrator'

@jlouros I've experienced both running non-elevated, and running as an Adminstrator

Does this happen for PS 7-preview1 as well? .Net Core 3 has improved COM interaction, it might be an issue of .Net Core 2.1.
Also: Maybe a similar improvement to the code similar to PR #7580 could help as well?

@bergmeister, I have had it happen with 7 preview as well, but much less often. 7 preview seems to give a CLR error dump, but it closes so quickly … but I got it:

I also don't experience this nearly as much when running 'as administrator', as @jlouros mentions, but as @Antaris said, it does still ocassionally happen.

We could get more information with debug build (we ignore errors in release build in the code!)

@SteveL-MSFT I opened an API proposal in WPF to get a sign off first (the proposed change is non-breaking, so it should be OK) and included some low level implementation details. I have not looked at the WPF code itself in detail but it should not be too difficult (the hardest part might be the testing)
https://github.com/dotnet/wpf/issues/950
This would be the way forward for PowerShell 7, as I start reading the WPF code in more detail, I will try to compare it to my implementation and see if I can improve the COM calls, I am wondering if this is a problem of the AppartmentState being MTA because I basically translated the C++ Windows PowerShell code to C# and used the interface definitions from the Windows API back when I originally did the implementation

@bergmeister I think for now, perhaps the interim solution is to wrap it in try...catch so that pwsh at least starts. We can take that fix to 6.2.x servicing. The proper fix can come later.

@SteveL-MSFT Are you sure a fatal CLR exception can be caught? Verifying the fix will be hard as I do not have an environment where I can reproduce this. I could try building a version of PowerShell with this fix and upload it here so that people in this issue test it?

@bergmeister I can't repro this myself. I think the best option might be as you suggest to build a private and ask someone who can repro it to try it out.

I see that we ignore return codes in the code that can be bad.

[edit] disregard my previous comment, even though [PreserveSig] attributes are wrong in multiple places, while making the PR to fix them I noticed they were only wrong on interface methods you didn't call.

I have the changes here if you want a PR anyways, but it shouldn't be the source of the crashes.

@weltkante Interesting, I took the interface definitions from the original Windows API pack (see e.g. here) and was not aware of this. I am not an expert in this area but if you think your changes make it better, please submit a PR.

@Antaris @jlouros @msftrncs @cpmcgrath
In PR #9896, I added a global catch around it and added logging to got more information out.
Please download the MSI from the PowerShell-CI-windows build of that PR. If you are not familiar with the system just use the direct link to the build here and click on the button on the top right, and then click on Artifacts and then the artifacts submenu. This will download you a zip and in there is the MSI, which is a custom version of PowerShell 7 from the lastest commit in master.

Please report if it fixes it and if not, please provide the log messages that get printed to the PowerShell console. It will log out all the stages the code goes through. If you see a message of the format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. please let us know because that would mean that the catch statement was able to catch the fatal CLR error (which I doubt at the moment).
This is just a test build and not intended for any supported use.
UPDATE (June 19): I updated the link to a newer build that should catch the exceptions inside the Task.Run statement as before it could've still leaked.

@bergmeister I've installed that Preview7 MSI and will get back to you as I try and recreate the issue, and run it for a couple of days as my main shell 👍

I see that we ignore return codes in the code that can be bad.

@iSazonov where do you see that? I just did a review of the COM interface declarations as well as the calling CreateElevatedEntry method and couldn't find anything obviously wrong, at least in the methods which are actually used. It looks like all methods declaring PreserveSig are checking their return codes (methods returning void and not declaring PreserveSig have their return code checked by the interop layer).

Anyways, not checking return codes cannot lead to AccessViolationException in coreclr. If the stacktrace from @anmenaga above is representative for the issue then it could very well be another bug in the coreclr interop layer (there already have been a few)

If your investigation doesn't lead anywhere it might be worth having someone from coreclr having a look at the dump. The stacktrace being in internal coreclr code really doesn't look very much like calling into wrongly coded interop declarations. In particular when in the coreclr RCWHolder helper class the line m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); returns NULL for the middle call of GetInteropInfoNoCreate then it didn't really get very far on making the crashing call. (This is what happened in the dump, no idea if its representative.)

I mean
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
In release build we ignore fail results.

@iSazonov ah ok, this doesn't really ignore the failure result, it just doesn't give out diagnostics. It still returns immediately, meaning the attempt to create the JumpList entry is aborted without doing any more COM calls. Doing a return certainly can't lead to the kind of crash we're seeing here.

I just had a look at WPF's implementation and its code checks that it is in STA apartment state. WPF threads are all in STA so I am not sure if this check is due to WPF or if STA is more suited for the COM calls that we make (PowerShell Core, even 7, is in MTA mode due to .Net Core historically not supporting STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

Usually COM handles the apartment for you, if you aren't on STA then CoCreateInstance will create a dedicated STA thread for the COM objects if they are registered as only running on STA.

PowerShell Core, even 7, is in MTA mode due to .Net Core historically not supporting STA

You can't just turn a thread to STA, if you do that then you need a message loop too. If you don't have a Windows message loop then you probably shouldn't be STA.

@Antaris Thanks. P.S.: If you see a message of the format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. please let us know because that would mean that the catch statement was able to catch the fatal CLR error (which I doubt at the moment).
In the meantime I suspect that this error happens rather on machines of different hardware spec, I tired with 1, 4 and 16 CPU cores . Can anyone share details?

@bergmeister I haven't been able to replicate the issue in the last few days. I'll keep at it, as I use PowerShell constantly.

I have also not encountered any exceptions.

For reference, my spec machine is:
Dell XPS 15 9570
Intel Core i7-8750H - 6 Core
32GB RAM

That is good but have you ever seen a message in the console saying something like
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught.?
Only if you've seen it then it would be the proof that the fatal CLR error could be caught successfully.

I can reproduce this bug every time if I try to run PowerShell. I will describe in 2 different Scenario, in the first one, it is working without any problems on the other hand with the second one not.
If needed i can provide more logs or outputs.

My Hardware :

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

My Software :

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

VS Code :
Version: 1.36.0-insider (system setup)
Commit: 68a7e5bc437b38d0281df0756997a25da2a2900c
Date: 2019-06-18T18:40:22.519Z
Electron: 4.2.4
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18917

PowerShell:
$PSVersionTable

Name Value
---- -----
PSVersion 7.0.0-preview.1
PSEdition Core
GitCommitId 7.0.0-preview.1
OS Microsoft Windows 10.0.18917
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Scenarios :

Scenario1 :

Steps :
1-try to right click a folder and select PowerShell preview 7 -> open here
Result :
works perfectly without any problem

Scenario2 :

Steps :
1-open a VS Code in an pipenv ( virtualenv) folder ( Right click a folder/directory and select Open with Code Insider )
2-wait until it initialize virtualenv
3-try to right click same folder and select PowerShell preview 7 -> open here ( or try to run it via shortcut )
Result :
Gives this error and close :
Internal CLR error. (0x80131506)
at Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry(System.String)
at Microsoft.PowerShell.ConsoleHost+<>c.b__4_0()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task+<>c.<.cctor>b__274_0(System.Object)
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread)
at System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread)
at System.Threading.Tasks.Task.ExecuteFromThreadPool(System.Threading.Thread)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

@usta Can you please describe what you mean by 'pipenv (virtualenv)', I do not use Python very much. Since you say you can always reproduce, please read my comment below, install the custom build and please report if it fixes it:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment-502053584

@usta Can you please describe what you mean by 'pipenv (virtualenv)', I do not use Python very much. Since you say you can always reproduce, please read my comment below, install the custom build and please report if it fixes it:
#9295 (comment)
@bergmeister
It looks like this one have fixed that bug ( if I have hit the same problem I will mention it here ) thanks

I cannot seem to reproduce it with the custom build, but it was pretty rare with 7 preview 1, yet 6.2 does it very regularly. There might be some usefulness in applying a patch to a custom build of 6.2, or a series of builds from 6.2. Just adding the debug/try/catch in might have changed something such a timing related resource lock up or something.

cc @TravisEz13 @adityapatwardhan we should consider taking @bergmeister's change to 6.2.2

@bergmeister can we reopen this bug please ?
Because i have hit same bug today again (with the one you have mentioned ( the custom build ) )
(or maybe a different one)

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

PS C:\Windows\System32> $PSVersionTable

Name Value
---- -----
PSVersion 7.0.0-preview2.25651
PSEdition Core
GitCommitId 7.0.0-preview2.25651
OS Microsoft Windows 10.0.18922
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

@usta Yes, I agree, we should re-open (I do not have the rights though but will notify maintainers). Thank you very much for reporting and providing the log, now we know that the problem happens on this line (should it happen again but with a different log where AddObject is not the last line before the crash let us know though):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89-L90
@daxian-dbw @SteveL-MSFT @iSazonov This means that despite initial positive reports that PR #9928 is not able to catch the fatal CLR error that has been reported multiple times (all bug reports reported the same error). Whilst there was still some value in doing a global catch for something that is not essential, the problem still persists... With the additional information I could try to look into seeing if we can code more defensively to avoid getting to this point where this issue happens (which I suspect to be a bug in the coreclr itself, is it worthwhile opening an issue there?). Otherwise I can only think of disabling this feature via e.g. an environment variable (or storing some info if the jumplist has been populated once already since it persists afterwards, not sure if it persists after Windows updates though...) Let me know what you think/prefer.
On a related note, I opened the following issue and PR in WPF to add the required APIs to radically simplify the code/responsibility in this repo going forward but so far the PR has not been reviewed and the issue has been tagged with .Net 5....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister now i tried again and again to reproduce same error.
At the end i may reproduce it but this time it give anohter log:

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Commit
CoCreateInstance
AddObject
Exception 'System.Runtime.InteropServices.InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used.
at System.StubHelpers.InterfaceMarshaler.ConvertToNative(Object objSrc, IntPtr itfMT, IntPtr classMT, Int32 flags)
at Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks(IObjectArray poa)
at Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry(String title)
at Microsoft.PowerShell.ConsoleHost.<>c.b__4_0()' with stack trace at System.StubHelpers.InterfaceMarshaler.ConvertToNative(Object objSrc, IntPtr itfMT, IntPtr classMT, Int32 flags)
at Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks(IObjectArray poa)
at Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry(String title)
at Microsoft.PowerShell.ConsoleHost.<>c.b__4_0() successfully caught.
PS C:\Users\usta>

If needed I will be glad to test another build or try to provide other logs ( which might need to overcome this bug )

@bergmeister
I am not even a m$ technology programmer but just because of curiosity isn't this line also needs an extra check before passing to AddUserTasks ?
( https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87 )
I mean isn't that might be better something like this :
hResult = pShortCutCollection.AddObject((IShellLinkW)nativePropertyStore);
if (hResult < 0)
{
pShortCutCollection.Clear();
Debug.Fail($"Couldnt add nativePropertyStore to Collection : HResult '{hResult}'.");
return;
}

Is it possible to detect if the jump list already exists (persists), and skip the steps to build it in that case?

@usta no, AddObject is declared as returning void and thus the interop layer will do the check (and throw an exception)

@msftrncs I don't know of any managed API which exposes reading of jumplists, so I suspect that the native API doesn't even support it, but I didn't check. In any way, just checking for existence is wrong, it would cause jumplists to become outdated if one of their properties changed.

In either way if you can't fix the problem here (and I seriously doubt adding try/catch for a coreclr panic is going to work nor a good idea) you should probably raise an issue with coreclr for further examination. You do have a dump to examine after all. The scenario in the dump certainly looks like a coreclr bug to me. (See my comment above for what goes wrong in the dump.)

I opened an issue with all the details in the CoreClr repo, maybe they can help us. I had a look at our code again and there is no more defensive way of querying an API if the jumplist has already been created, we only get the maximum number of available slots available and already return early if there is not enough space for the jumplist, all we could do is cache the jumplist internally or have something like a feature flag to skip the problematic jumplist creation code (once the jumplist entry has been created, it persists).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister I have tried latest daily build and it looks like in this build I couldn't reproduce the bug.
Whether it is fixed or the reason for that bug gone.

PS C:\Users\usta> echo $PSVersionTable

Name Value
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition Core
GitCommitId 7.0.0-dailypreview2.26796
OS Microsoft Windows 10.0.18922
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Everyone: The CoreClr team has investigated the issue and the problem is that the COM APIs that are being called are strictly STA only (PS Core currently still operates in MTA until #7216 is resolved) and the coreclr did not provide any warnings/errors. Therefore I've pushed changes to create the JumpList in an STA thread, which should hopefully be the final resolution.
Please re-test with the latest build of PR #9896 and provide feedback

Everyone: The fix for this issue has been backported to the recent release of 6.2.2, please update and provide feedback if it fixed it. Users of the preview will have to wait for 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

:tada:This issue was addressed in #10057, which has now been successfully released as v7.0.0-preview.2.:tada:

Handy links:

• Release Notes

:tada:This issue was addressed in #9928, which has now been successfully released as v7.0.0-preview.2.:tada:

Handy links:

• Release Notes