यह वीएस कोड या वीएस कोड पर पावरशेल एक्सटेंशन से संबंधित हो सकता है। अपने सिस्टम को रिबूट करने के बाद, मैं बिना किसी समस्या के तुरंत पॉवरशेल खोलने में सक्षम था। वीएस कोड खुला होने के साथ, पॉवरशेल के गैर-प्रशासनिक सत्र खुले रहने से इनकार करते हैं। VS कोड बंद करने के बाद भी, PowerShell मज़बूती से खोलने से इनकार करने लगता है।

आप cmd.exe से PowerShell Core चला सकते हैं और एक त्रुटि संदेश देख सकते हैं।

जब मैं शीघ्र ही CMD से PWSH को खोलने का प्रयास करता हूं, तो PowerShell ठीक शुरू हो जाता है। पावरशेल के उस सत्र के साथ भी, टास्कबार आइकन से इसे खोलने का प्रयास करने से परिणाम नहीं खुलता है। मैंने एक एक्सप्लोरर एड्रेस बार में PWSH टाइप करने की कोशिश की और वही नो-ओपन रिजल्ट प्राप्त किया।

नहीं खुलने से, यही होता है। एक विंडो पॉप अप होती है, और हेडर की जानकारी होती है:
`` `
पॉवरशेल 6.2.0
कॉपीराइट (c) Microsoft Corporation। सभी अधिकार सुरक्षित।

https://aka.ms/pscore6-docs
सहायता प्राप्त करने के लिए 'सहायता' टाइप करें।
`` ``
कमांड प्रॉम्प्ट कभी प्रकट नहीं होता है, और थोड़ी देरी के बाद, विंडो बंद हो जाती है।

अगर मैं सिस्टम को कुछ समय के लिए छोड़ देता हूं (मिनट, शायद 10 मिनट, लेकिन मैं सिस्टम पर अन्य कार्य करना जारी रखता हूं) तो पावरस्क्रिन काम को ठीक से खोलना। मैं पैटर्न को दोहराने में सक्षम हूं। PowerShell ठीक खुलने के बाद, मैं VS कोड बंद कर देता हूं (यदि यह खुला भी था), थोड़ा इंतजार करें, VS कोड फिर से खोलें, थोड़ा इंतजार करें (शायद एक मिनट) और फिर PowerShell फिर से खुलने में विफल हो जाए, और यह कुछ समय के लिए फिर से बना रहे ।

मैंने कल रात अपने 19H1 के इनसाइडर मशीन पर यह सब दोहराने की कोशिश की, और यह पहली बार नहीं दोहराएगा। पहली बार पॉवरशेल खोलने में विफल रहा, लेकिन बाद में हर बार काम किया, एक रिबूट के बाद भी।

जब मैं शीघ्र ही CMD से PWSH खोलने का प्रयास करता हूं,

हमेशा?

यदि आप PowerShell Core घर निर्देशिका खोलते हैं और pwsh.exe पर डबल क्लिक करते हैं - तो क्या यह किसी भी समय में अच्छी तरह से शुरू होता है?

जब मैं शीघ्र ही CMD से PWSH खोलने का प्रयास करता हूं,

हमेशा?

अब तक। मैं एक PWSH विंडो आज़माऊँगा, यह विफल होगा, मैं CMD खोलूँगा, PWSH टाइप करूँगा, यह ठीक शुरू हुआ, एक और PWSH विंडो आज़माएँ, यह विफल हो जाएगा। PWSH के CMD उदाहरण से बाहर निकलें और पुनः प्रयास करें, यह फिर से ठीक खुल जाएगा। मैं दोहराता रहूंगा, CMD विंडो को पूरी तरह से बंद करना, फिर भी शुरू करना, अभी भी एक CMD प्रॉम्प्ट पर PWSH हमेशा काम करता प्रतीत होता है।

इसके अलावा, मैं पूरी तरह से कसम नहीं खाऊंगा, कि PWSH विंडो के एक उदाहरण के बाद भी सफलतापूर्वक खुल जाता है, कुछ मिनट बाद फिर से प्रयास करता है और यह फिर से नहीं खुलेगा, बिना किसी विशेष कारण के मैं अभी तक कटौती कर सकता हूं।

यदि आप PowerShell Core घर निर्देशिका खोलते हैं और pwsh.exe पर डबल क्लिक करते हैं - तो क्या यह किसी भी समय में अच्छी तरह से शुरू होता है?

यह एक ही नहीं खुले हालत हो रहा है। हालांकि यह अजीब है, क्योंकि EXE फ़ाइल पर सीधे क्लिक करने पर ज्यादातर समय समान-खुली स्थिति में परिणाम मिलता है, लेकिन स्टार्ट मेनू फ़ोल्डर में संग्रहीत शॉर्ट-कट पर क्लिक करना अधिक छिटपुट लगता है, जो अक्सर सफलतापूर्वक खुलता है, लेकिन निश्चित रूप से हमेशा नहीं ।

विंडोज ओएस हर (कंसोल) एप्लिकेशन के लिए एक विंडो पैरामीटर रखता है। ऐसा लगता है कि पैरामीटर टूट गया है और हमें उन्हें रजिस्ट्री से साफ करने की आवश्यकता है।

मुझे भी यह अनुभव हो रहा है। यदि यह मदद करता है, तो ईवेंट व्यूअर में निम्न प्रकट होता है:

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: 

मैं अभी भी PowerShell पूर्वावलोकन एक्सटेंशन के साथ VS कोड खोलने के लिए इसे सहसंबद्ध देख रहा हूं, लेकिन मुझे लगता है कि अन्य अनुप्रयोग जो उपयोग करते हैं। .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 रनटाइम

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 त्रुटि रिपोर्टिंग द्वारा एकत्रित जानकारी संलग्न की है।
रिपोर्ट। ज़िप

अवलोकन:

• मैं विंडोज v1903 (ओएस बिल्ड 18362.30) चला रहा हूं
• मेरे पास पॉवरशेल एक्सटेंशन (v2019.5.0) के साथ विजुअल स्टूडियो कोड (v1.35.0) स्थापित है
• यह एक रिबूट के बाद होने लगता है
• प्रोफ़ाइल लोड समय में कुछ समय लगता है
• यह कभी-कभी Adminsitrative मोड में होता है, और कभी-कभी नहीं
• मेरे पास मेरी प्रोफ़ाइल के भाग के रूप में 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 यदि आप रेपो को फोर्क और बिल्ड कर सकते हैं - डिबग मोड के साथ आप अपवाद में अधिक जानकारी प्राप्त कर सकते हैं।

@ स्टीवएल-एमएसएफटी क्या हमें 6.2 संस्करण के बारे में चिंतित होना चाहिए?

मॉड्यूल नाम को दोष देने से मुझे लगता है कि .NET समस्या है। इसी तरह की बात पहले भी हुई थी।
इस बीच, यहां सभी विवरणों के साथ दुर्घटनाग्रस्त प्रक्रिया का एक डंप प्राप्त करने का एक सरल तरीका है जो जांच और ठीक करने में बहुत मदद करेगा। @ अतारिस - आप ProcDump उपयोगिता की कोशिश कर सकते हैं:

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

अगली बार PS के क्रैश होने पर, विस्तृत त्रुटि जानकारी वाला डंप निर्दिष्ट फ़ोल्डर में लिखा जाएगा।

@anmenaga

मैं आज सुबह इस अनुभव को ट्रिगर करने में कामयाब रहा। मेरे लैपटॉप का ताज़ा री-स्टार्ट। पहली बार जब मैंने पॉवरशेल कोर खोला, तो यह ठीक था। फिर मैंने अपने PS Core प्रोफाइल को पढ़ने के लिए Visual Studio Code का उपयोग किया, और _without में बदलाव करके एक बचत शुरू की। मैंने तब 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 कॉल को बेहतर बनाने की कोशिश की है। इस मामले में मुझे बल्कि संदेह है कि 19H1 का उपयोग किया गया विंडोज इनसाइडर एक अपराधी भी हो सकता है।
मैंने एक ही COM कॉल का उपयोग करके Windows PowerShell से C # के मूल C ++ कोड को पोर्ट किया और COM इंटरफ़ेस परिभाषाओं के लिए Windows Api पैक स्रोत कोड का उपयोग किया।
अच्छी खबर यह है कि यह कोड केवल तब चलता है जब pwsh अंतःक्रियात्मक रूप से शुरू होता है और यह है कि जम्पलिस्ट मेनू पंजीकरण केवल एक बार ही होना चाहिए (ऐसे कोड जो जाँचता है कि निहित है)। हो सकता है कि हमें इसके चारों ओर एक कोशिश {} कैच ब्लॉक डालनी चाहिए और केवल विफलता स्टैक ट्रेस को लॉग आउट करना चाहिए?
आम तौर पर बोलते हुए, जब मैंने ऐसा किया था तो मुझे विंडोज़ एपी पैक का पूरा .Net कोड .Net कोर में पोर्ट करना पड़ा और ऊंचाई के साथ जम्पस्टार्ट प्रविष्टि के लिए अनुमति देने के लिए इसे ट्वीक किया। 2 हफ्ते पहले, WPF ने जंपलिस्ट के लिए सोर्स कोड जोड़ा और एक पीआर के साथ एक एलिवेटेड जम्पलिस्ट के लिए हम बहुत सारे कामों को सिर्फ कुछ लाइनों के लिए टाल सकते थे, लेकिन अंततः मुझे लगता है कि यह एक .Net कोर समस्या है।

@bergmeister आप इस काम पर लेने के लिए तैयार हैं? कृप्या :)

मैं कोशिश कर सकता हूं, डब्ल्यूपीएफ एपीआई को एक उन्नत बूलियन पैरामीटर की तरह कुछ की आवश्यकता होगी (झूठा करने के लिए डिफ़ॉल्ट) जंपलिस्ट प्रविष्टि को उन्नत मोड में आवेदन को खोलने के लिए। यह इस बात पर निर्भर करेगा कि एपीआई परिवर्तन को स्वीकार करने के इच्छुक डब्ल्यूपीएफ के लोग कितने लचीले हैं और पीआर विलय प्राप्त करना कितना कठिन है, लेकिन मुझे लगता है कि यह समय के खिलाफ दौड़ होगी क्योंकि नेट कोर 3 जुलाई के आसपास आरसी प्रकाशित करना चाहता है। (अर्थ है कि वे उस समय के बाद इस तरह के बदलावों को स्वीकार करने की संभावना कम है) ...।
अन्यथा एकमात्र विकल्प त्रुटि को पकड़ने की कोशिश करना होगा (लेकिन मेरे लिए यह एक अप्राप्य, घातक सीएलआर त्रुटि जैसा दिखता है)।
मैंने स्वयं दुर्भाग्य से ऐसी त्रुटियों का कभी अनुभव नहीं किया है

यह जीयूआई में एक दौड़ की स्थिति लगती है।

@ स्टीवएल-एमएसएफटी 6.2 संस्करण के बारे में स्पष्ट नहीं है - क्या हमें इसे भी ठीक करना चाहिए?

किसी भी डेटा के बिना अपने अगले बयान का समर्थन करने के लिए, ऐसा लगता है कि यह समस्या लगभग कभी नहीं होती है अगर मैं पावरशेल को 'रन के रूप में प्रशासक' के साथ खोलता हूं

@jlouros मैंने दोनों को गैर-उन्नत, और एक प्रशासक के रूप में चलाने का अनुभव किया है

क्या यह PS 7-प्रीव्यू 1 के लिए भी होता है? .Net Core 3 ने COM इंटरैक्शन में सुधार किया है, यह .Net Core 2.1 का मुद्दा हो सकता है।
इसके अलावा: शायद PR # 7580 के समान कोड में भी सुधार हो सकता है?

@bergmeister , मैं 7 पूर्वावलोकन के साथ भी ऐसा हुआ है, लेकिन बहुत कम बार। 7 पूर्वावलोकन सीएलआर त्रुटि डंप देने के लिए लगता है, लेकिन यह इतनी जल्दी बंद हो जाता है ... लेकिन मुझे यह मिल गया:

जब तक ' @ प्रशासक' के रूप में चलाने के बारे में मुझे यह अनुभव नहीं होता, जैसा कि @Antaris ने कहा, यह अभी भी

हम डिबग बिल्ड के साथ अधिक जानकारी प्राप्त कर सकते हैं (हम कोड में रिलीज़ बिल्ड में त्रुटियों को अनदेखा करते हैं!)

@ स्टीवएल-एमएसएफटी मैंने पहली बार साइन ऑफ करने के लिए डब्ल्यूपीएफ में एक एपीआई प्रस्ताव खोला (प्रस्तावित परिवर्तन गैर-ब्रेकिंग है, इसलिए यह ठीक होना चाहिए) और कुछ निम्न स्तर के कार्यान्वयन विवरण शामिल हैं। मैंने स्वयं WPF कोड को विस्तार से नहीं देखा है लेकिन यह बहुत मुश्किल नहीं होना चाहिए (सबसे कठिन हिस्सा परीक्षण हो सकता है)
https://github.com/dotnet/wpf/issues/950
यह PowerShell 7 के लिए आगे का रास्ता होगा, क्योंकि मैं WPF कोड को और अधिक विस्तार से पढ़ना शुरू करता हूं, मैं इसे अपने कार्यान्वयन से तुलना करने की कोशिश करूंगा और देखूंगा कि क्या मैं COM कॉल में सुधार कर सकता हूं, मैं सोच रहा हूं कि क्या यह समस्या है? AppartmentState MTA कारण मैंने मूल रूप से C ++ Windows PowerShell कोड को C # में अनुवादित किया और जब मैंने मूल रूप से कार्यान्वयन किया था, तो Windows API से इंटरफ़ेस परिभाषाओं का उपयोग किया था

@bergmeister मुझे लगता है कि अब के लिए, शायद अंतरिम समाधान यह कोशिश में लपेटने के लिए है ... पकड़ ताकि pwsh कम से कम शुरू होता है। हम उस फिक्स को 6.2.x सर्विसिंग में ले सकते हैं। उचित निर्धारण बाद में आ सकता है।

@ स्टीवएल-एमएसएफटी क्या आप सुनिश्चित हैं कि एक घातक सीएलआर अपवाद पकड़ा जा सकता है? फिक्स को सत्यापित करना कठिन होगा क्योंकि मेरे पास ऐसा वातावरण नहीं है जहां मैं इसे पुन: पेश कर सकता हूं। मैं इस सुधार के साथ PowerShell का एक संस्करण बनाने की कोशिश कर सकता हूं और इसे यहां अपलोड कर सकता हूं ताकि इस मुद्दे के लोग इसका परीक्षण करें?

@bergmeister मैं इसे स्वयं नहीं

मैं देखता हूं कि हम कोड में रिटर्न कोड को अनदेखा करते हैं जो खराब हो सकता है।

[संपादित करें] मेरी पिछली टिप्पणी की अवहेलना करते हैं, भले ही [PreserveSig] विशेषताएँ कई स्थानों पर गलत हैं, जबकि पीआर को उन्हें ठीक करने के लिए मैंने देखा कि वे केवल उन इंटरफ़ेस विधियों पर गलत थे जिन्हें आपने कॉल नहीं किया था।

अगर आप पीआर रास्ते चाहते हैं तो मेरे पास हैं , लेकिन यह क्रैश का स्रोत नहीं होना चाहिए।

@weltkante दिलचस्प, मैंने मूल विंडोज एपीआई पैक से इंटरफ़ेस परिभाषाएँ लीं (उदाहरण के लिए यहां देखें) और इसके बारे में पता नहीं था। मैं इस क्षेत्र का विशेषज्ञ नहीं हूं, लेकिन अगर आपको लगता है कि आपके बदलाव इसे बेहतर बनाते हैं, तो कृपया एक पीआर सबमिट करें।

@Antaris @jlouros @msftrncs @cpmcgrath
PR # 9896 में, मैंने इसके चारों ओर एक वैश्विक पकड़ जोड़ी और अधिक जानकारी प्राप्त करने के लिए लॉगिंग को जोड़ा।
कृपया उस PR के PowerShell-CI-windows बिल्ड से MSI डाउनलोड करें। यदि आप सिस्टम से परिचित नहीं हैं, तो यहां बिल्ड के लिए सीधे लिंक का उपयोग Artifacts और फिर artifacts सबमेनू पर क्लिक करें। यह आपको एक ज़िप डाउनलोड करेगा और इसमें MSI है, जो कि मास्टर में अंतिम प्रतिबद्ध से PowerShell 7 का कस्टम संस्करण है।

कृपया रिपोर्ट करें कि क्या यह इसे ठीक करता है और यदि नहीं, तो कृपया लॉग संदेश प्रदान करें जो कि PowerShell कंसोल पर मुद्रित हो। यह उन सभी चरणों को लॉग आउट करेगा, जो कोड के माध्यम से जाता है। यदि आपको प्रारूप Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. का संदेश दिखाई देता है, तो कृपया हमें बताएं क्योंकि इसका अर्थ यह होगा कि catch कथन घातक CLR त्रुटि को पकड़ने में सक्षम था (जिस पर मुझे फिलहाल संदेह है)।
यह सिर्फ एक परीक्षण निर्माण है और किसी भी समर्थित उपयोग के लिए अभिप्रेत नहीं है।
अद्यतन (19 जून): मैंने एक नए निर्माण की कड़ी को अद्यतन किया, जो कि Task.Run विवरण के अंदर अपवादों को पकड़ लेना चाहिए क्योंकि यह अभी भी लीक हो सकता है।

@bergmeister मैंने उस पूर्वावलोकन 7 MSI को स्थापित किया है और जैसा कि मैंने कोशिश की और समस्या को पुन: उत्पन्न करेगा, और इसे अपने मुख्य शेल के रूप में कुछ दिनों के लिए चलाऊंगा installed

मैं देखता हूं कि हम कोड में रिटर्न कोड को अनदेखा करते हैं जो खराब हो सकता है।

@iSazonov आप कहाँ देखते हैं? मैंने सिर्फ COM इंटरफ़ेस घोषणाओं के साथ-साथ CreateElevatedEntry पद्धति की समीक्षा की और कुछ भी स्पष्ट रूप से गलत नहीं पाया, जो कि वास्तव में उपयोग किए जा रहे तरीकों में है। ऐसा लगता है कि सभी तरीके घोषित कर रहे हैं PreserveSig अपने रिटर्न कोड की जाँच कर रहे हैं (विधियाँ वापस लौटने की घोषणा नहीं कर रहे हैं और PreserveSig ने अपने रिटर्न कोड को इंटरोप परत द्वारा जाँच किया है)।

वैसे भी, रिटर्न कोड की जाँच नहीं करने से coreclr में AccessViolationException नहीं हो सकती है। यदि @anmenaga के ऊपर का स्टैकट्रेस इस मुद्दे के लिए प्रतिनिधि है तो यह coreclr इंटरोप लेयर में एक और बग हो सकता है (वहां पहले से ही कुछ है)

यदि आपकी जांच कहीं भी नहीं होती है तो यह किसी व्यक्ति के डंप पर नज़र रखने के लायक हो सकता है। स्टैकट्रेस आंतरिक coreclr कोड में होने के कारण वास्तव में गलत कोडित इंटरोप घोषणाओं में कॉल करने की तरह नहीं दिखता है। विशेष रूप से जब coreclr RCWHolder हेल्पर क्लास में m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); लाइन रिटर्न GetInteropInfoNoCreate के मिडल कॉल के लिए NULL होता है, तब क्रैश कॉल करने पर यह वास्तव में बहुत दूर नहीं होता है। (डंप में ऐसा ही हुआ, इसके प्रतिनिधि को पता नहीं।)

मेरा मतलब
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
रिलीज बिल्ड में हम असफल परिणामों को नजरअंदाज करते हैं।

@iSazonov आह ठीक है, यह वास्तव में विफलता के परिणाम की अनदेखी नहीं करता है, यह सिर्फ निदान नहीं देता है। यह अभी भी तुरंत लौटता है, जिसका अर्थ है कि जंपलिस्ट प्रविष्टि बनाने का प्रयास बिना किसी COM कॉल के किया जाता है। निश्चित रूप से एक वापसी करने से उस तरह की दुर्घटना नहीं हो सकती है जैसा हम यहां देख रहे हैं।

मुझे WPF के कार्यान्वयन और इसके कोड की जाँच पर एक नज़र थी कि यह STA अपार्टमेंट राज्य में है। WPF थ्रेड्स सभी STA में हैं, इसलिए मुझे यकीन नहीं है कि यह चेक WPF के कारण है या यदि STA COM कॉल के लिए अधिक अनुकूल है जो हम बनाते हैं (PowerShell Core, यहां तक ​​कि 7, MTA मोड में है। नेट कोर इतिहास का समर्थन नहीं कर रहा है। एसटीए):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Whatf/src/PresentationFramework/System/Whell/JumpList#ist#ist

आमतौर पर COM आपके लिए अपार्टमेंट को संभालता है, अगर आप STA पर नहीं हैं तो CoCreateInstance COM वस्तुओं के लिए एक समर्पित STA थ्रेड बनाएगा यदि वे केवल STA पर चलने के रूप में पंजीकृत हैं।

PowerShell Core, यहां तक ​​कि 7, MTA मोड में है। नेट कोर ऐतिहासिक रूप से STA का समर्थन नहीं करता है

आप सिर्फ STA के लिए एक धागा नहीं बदल सकते हैं, यदि आप ऐसा करते हैं तो आपको एक संदेश लूप की भी आवश्यकता है। यदि आपके पास विंडोज मैसेज लूप नहीं है, तो संभवतः आपको एसटीए नहीं होना चाहिए।

@Antaris धन्यवाद पुनश्च: यदि आपको Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. का एक संदेश दिखाई देता है तो कृपया हमें बताएं क्योंकि इसका अर्थ यह होगा कि catch कथन घातक सीएलआर त्रुटि (जिसे मैं वर्तमान में संदेह करता हूं) को पकड़ने में सक्षम था।
इस बीच मुझे संदेह है कि यह त्रुटि विभिन्न हार्डवेयर युक्ति की मशीनों पर होती है, मैं 1, 4 और 16 सीपीयू कोर के साथ थक गया। क्या कोई विवरण साझा कर सकता है?

@bergmeister मैं पिछले कुछ दिनों में इस मुद्दे को दोहराने में सक्षम नहीं था। मैं इसे रखूंगा, क्योंकि मैं लगातार PowerShell का उपयोग करता हूं।

मुझे भी किसी अपवाद का सामना नहीं करना पड़ा है।

संदर्भ के लिए, मेरी कल्पना मशीन है:
डेल एक्सपीएस 15 9570
इंटेल कोर i7-8750H - 6 कोर
32 जीबी रैम

यह अच्छा है, लेकिन क्या आपने कभी सांत्वना में एक संदेश देखा है जैसे कुछ कहते हैं
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
केवल अगर आपने इसे देखा है तो यह इस बात का प्रमाण होगा कि घातक सीएलआर त्रुटि को सफलतापूर्वक पकड़ा जा सकता है।

यदि मैं PowerShell चलाने का प्रयास करता हूं तो मैं हर बार इस बग को पुन: पेश कर सकता हूं। मैं 2 अलग-अलग परिदृश्यों में वर्णन करूंगा, पहले एक में, यह दूसरी तरफ बिना किसी समस्या के काम कर रहा है।
यदि आवश्यक हो तो मैं अधिक लॉग या आउटपुट प्रदान कर सकता हूं।

मेरे हार्डवेयर:

लेनोवो Y520
इंटेल I7 7700HQ (2.8Ghz)
16 जीबी राम
सैमसंग 512 970Pro एसएसडी
वेस्टर्नडिजिटल WD10SPCX 1TB HDD
एनवीडिया 1050TI GPU 4GB

मेरा सॉफ्टवेयर:

OS:
एम $ विंडोज 10 - संस्करण १ ९ ०३ - ओस्बिल्ड 18917.1000

वीएस कोड:
संस्करण: 1.36.0-अंदरूनी सूत्र (सिस्टम सेटअप)
प्रतिबद्ध: 68a7e5bc437b38d0281df0756997a25da2a2900c
दिनांक: 2019-06-18T18: 40: 22.519Z
इलेक्ट्रॉन: 4.2.4
क्रोम: 69.0.3497.128
नोड.जेएस: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18917

शक्ति कोशिका:
$ PSVersionTable

नाम मान
---- -----
PSVersion 7.0.0-पूर्वावलोकन.1
PSEdition Core
GitCommitId 7.0.0-पूर्वावलोकन 1
ओएस माइक्रोसॉफ्ट विंडोज 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-वीएस कोड खोलें (फोल्डर / डायरेक्टरी पर राइट क्लिक करें और कोड इनसाइडर के साथ ओपन खोलें)
2-प्रतीक्षा करें जब तक यह virtualenv को इनिशियलाइज़ नहीं करता है
3-एक ही फ़ोल्डर पर राइट-क्लिक करने और PowerShell पूर्वावलोकन 7 का चयन करने की कोशिश करें -> यहां खोलें (या शॉर्टकट के माध्यम से इसे चलाने का प्रयास करें)
परिणाम :
यह त्रुटि देता है और करीब:
आंतरिक सीएलआर त्रुटि। (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.ConcxtCallback, System.Object) पर
System.Threading.Tasks.Task.ExecuteWithThreadLocal पर
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 क्या आप कृपया
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -5020520584

@usta क्या आप कृपया
# 9295 (टिप्पणी)
@bergmeister
ऐसा लगता है कि इसने एक बग तय किया है (यदि मैंने उसी समस्या को मारा है तो मैं यहां इसका उल्लेख करूंगा) धन्यवाद

मैं कस्टम बिल्ड के साथ इसे पुन: पेश नहीं कर सकता, लेकिन यह 7 पूर्वावलोकन 1 के साथ बहुत दुर्लभ था, फिर भी 6.2 यह बहुत नियमित रूप से करता है। 6.2 के कस्टम बिल्ड पर पैच लगाने में कुछ उपयोगिता हो सकती है, या 6.2 से बिल्ड की श्रृंखला हो सकती है। बस डिबग / कोशिश / पकड़ को जोड़ने से इस तरह के समय संबंधी संसाधन लॉक अप या कुछ और बदल सकते हैं।

cc @ TravisEz13 @adityapatwardhan हमें @bergmeister का परिवर्तन 6.2.2 करने पर विचार करना चाहिए

@bergmeister क्या हम इस बग को फिर से खोल सकते हैं?
क्योंकि मैंने आज फिर वही बग मारा है (जिसका आपने उल्लेख किया है (कस्टम बिल्ड))
(या शायद एक अलग)

GetStartupInfo
CoCreateInstance
शुरुआत
मूल्य ते करना
कमिट
CoCreateInstance
AddObject
आंतरिक सीएलआर त्रुटि। (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.ConcxtCallback, System.Object) पर
System.Threading.Tasks.Task.ExecuteWithThreadLocal पर
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 Core
GitCommitId 7.0.0-पूर्वावलोकन 2.25651
ओएस माइक्रोसॉफ्ट विंडोज 10.0.18922
प्लेटफ़ॉर्म Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
क्रमांकन 1.1.0.1
WSManStackVersion 3.0

@usta हां, मैं सहमत हूं, हमें फिर से खुला होना चाहिए (मेरे पास हालांकि अधिकार नहीं हैं लेकिन रख-रखाव को अधिसूचित करेंगे)। लॉग को रिपोर्ट करने और प्रदान करने के लिए बहुत-बहुत धन्यवाद, अब हम जानते हैं कि समस्या इस रेखा पर होती है (क्या यह फिर से होना चाहिए लेकिन एक अलग लॉग के साथ जहां AddObject क्रैश से पहले अंतिम पंक्ति नहीं है, हालांकि हमें बताएं ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell .ConsoleHost / TaskbarJumpList.cs#8989
@ daxian-dbw @ SteveL-MSFT @iSazonov इसका मतलब यह है कि प्रारंभिक सकारात्मक रिपोर्टों के बावजूद कि PR # 9928 घातक सीएलआर त्रुटि को पकड़ने में सक्षम नहीं है जो कि कई बार रिपोर्ट की गई है (सभी बग रिपोर्ट में एक ही त्रुटि की सूचना दी गई है)। जब भी किसी चीज के लिए वैश्विक पकड़ बनाने में कुछ मूल्य था जो जरूरी नहीं है, समस्या अभी भी बनी हुई है ... अतिरिक्त जानकारी के साथ मैं यह देखने की कोशिश कर सकता हूं कि क्या हम इस बिंदु पर जाने से बचने के लिए अधिक रक्षात्मक रूप से कोड कर सकते हैं जहां यह मुद्दा होता है (जो मुझे खुद coreclr में एक बग होने का संदेह है, क्या यह वहाँ एक मुद्दा खोलने योग्य है?)। अन्यथा मैं केवल एक पर्यावरण चर के माध्यम से इस सुविधा को अक्षम करने के बारे में सोच सकता हूं (या कुछ जानकारी संग्रहीत कर रहा हूं यदि जंपलिस्ट एक बार पहले से ही आबाद हो गया है क्योंकि यह बाद में बनी रहती है, तो सुनिश्चित करें कि अगर यह विंडोज अपडेट के बाद भी बना रहता है ...) मुझे बताएं कि आप सोचना / पसंद करना।
संबंधित नोट पर, मैंने WPF में निम्नलिखित मुद्दे और PR को खोला और आवश्यक एपीआई को जोड़ने के लिए इस रेपो में कोड / जिम्मेदारी को सरल बनाने के लिए आगे बढ़ रहा है, लेकिन अभी तक पीआर की समीक्षा नहीं की गई है और इस मुद्दे को .Net 5 साथ टैग किया गया है
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister अब मैंने फिर से उसी त्रुटि को पुन: पेश करने की कोशिश की।
अंत में मैं इसे पुन: पेश कर सकता हूं, लेकिन इस बार यह लॉगर लॉग देगा:

GetStartupInfo
CoCreateInstance
शुरुआत
मूल्य ते करना
कमिट
CoCreateInstance
AddObject
अपवाद 'System.Runtime.InteropServices.InvalidComObjectException: COM ऑब्जेक्ट जिसे उसके अंतर्निहित RCW से अलग किया गया है, उसका उपयोग नहीं किया जा सकता।
सिस्टम।
Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa) पर
Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (स्ट्रिंग शीर्षक) पर
Microsoft.PowerShell.ConsoleHost पर। <> cb__4_0 () 'System.StubHelpers.InterfaceMarshaler.ConvertToNative (ऑब्जेक्ट objSrc, IntPtr itfMT, IntPtr classMT, Int32 झंडे) पर स्टैक ट्रेस के साथ)
Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa) पर
Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (स्ट्रिंग शीर्षक) पर
Microsoft.PowerShell.ConsoleHost पर। <> cb__4_0 () सफलतापूर्वक पकड़ा गया।
PS C: \ Users \ usta>

यदि आवश्यक हो तो मुझे किसी अन्य बिल्ड का परीक्षण करने या अन्य लॉग प्रदान करने का प्रयास करने में खुशी होगी (जिसे इस बग को दूर करने की आवश्यकता हो सकती है)

@bergmeister
मैं $ तकनीक प्रोग्रामर भी नहीं हूं, लेकिन सिर्फ जिज्ञासा के कारण इस लाइन को भी AddUserTasks से गुजरने से पहले अतिरिक्त जांच की आवश्यकता नहीं है?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495ff88fc889c58932d0b4020603/src/Microsoft.PowerLhell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#87
मेरा मतलब यह नहीं है कि ऐसा कुछ बेहतर हो सकता है:
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
अगर (hResult <0)
{{
pShortCutCollection.Clear ();
डीबग.फेल ($ "में मूलप्रकृति को संग्रह करने के लिए जोड़ नहीं सकता: HResult '{hResult}'"।);
वापसी;
}

क्या यह पता लगाना संभव है कि क्या जम्प सूची पहले से मौजूद है (जारी रहती है), और उस स्थिति में इसे बनाने के लिए कदमों को छोड़ दें?

@usta नहीं, AddObject को शून्य लौटाने के रूप में घोषित किया गया है और इस प्रकार इंटरोप लेयर चेक करेगी (और एक अपवाद फेंकें)

@msftrncs मैं किसी भी प्रबंधित एपीआई के बारे में नहीं जानता, जो कि

किसी भी तरह से अगर आप यहां समस्या को ठीक नहीं कर सकते हैं (और मैं एक coreclr आतंक के लिए कोशिश / पकड़ जोड़ने पर गंभीरता से संदेह करता हूं, तो काम करने जा रहा है और न ही एक अच्छा विचार) आपको संभवतः आगे की परीक्षा के लिए coreclr के साथ एक मुद्दा उठाना चाहिए। तुम सब के बाद जांच करने के लिए एक डंप है। डंप में परिदृश्य निश्चित रूप से मुझे एक coreclr बग की तरह दिखता है। (डंप में क्या गलत हुआ, इसके लिए मेरी

मैंने CoreClr रेपो में सभी विवरणों के साथ एक मुद्दा खोला, शायद वे हमारी मदद कर सकते हैं। मेरे पास हमारे कोड पर फिर से एक नज़र थी और एपीआई को क्वेरी करने का कोई और अधिक रक्षात्मक तरीका नहीं है यदि जम्पलिस्ट पहले से ही बनाया गया है, तो हम केवल उपलब्ध स्लॉट की अधिकतम संख्या प्राप्त करते हैं और पहले से ही जल्दी वापस आ जाते हैं यदि जम्परिस्ट के लिए पर्याप्त जगह नहीं है , हम सब कर सकते हैं आंतरिक रूप से जम्पलिस्ट को कैश करना या समस्याग्रस्त जम्पलिस्ट क्रिएशन कोड को छोड़ने के लिए एक फीचर फ्लैग की तरह कुछ है (एक बार जम्पलिस्ट एंट्री होने के बाद, यह बनी रहती है)।
https://github.com/dotnet/coreclr/issues/25502

@bergmeister मैंने नवीनतम दैनिक निर्माण की कोशिश की है और ऐसा लगता है कि इस निर्माण में मैं बग को पुन: पेश नहीं कर सका।
चाहे वह तय हो या उस बग का कारण।

PS C: \ Users \ usta> गूंज $ PSVersionTable

नाम मान
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition Core
GitCommitId 7.0.0-dailypreview2.26796
ओएस माइक्रोसॉफ्ट विंडोज 10.0.18922
प्लेटफ़ॉर्म Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
क्रमांकन 1.1.0.1
WSManStackVersion 3.0

हर कोई: CoreClr टीम ने इस मुद्दे की जांच की है और समस्या यह है कि जिन COM API को कॉल किया जा रहा है वे सख्ती से केवल STA हैं (PS Core अभी भी MTA में # 7216 हल होने तक संचालित होता है) और coreclr ने कोई चेतावनी / त्रुटियां प्रदान नहीं की हैं। इसलिए मैंने 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

: टाडा: इस मुद्दे को # 10057 में संबोधित किया गया था, जिसे अब v7.0.0-preview.2 रूप में सफलतापूर्वक जारी किया गया है।

काम लिंक:

• रिलीज नोट्स

: टाडा: इस मुद्दे को # 9928 में संबोधित किया गया था, जिसे अब v7.0.0-preview.2 रूप में सफलतापूर्वक जारी किया गया है।

काम लिंक:

• रिलीज नोट्स