قد يكون مرتبطًا بـ VS Code أو ملحق PowerShell في VS Code. بعد إعادة تشغيل نظامي ، تمكنت من فتح PowerShell على الفور دون أي مشكلة. مع فتح VS Code ، ترفض الجلسات غير الإدارية لـ PowerShell أن تظل مفتوحة. حتى بعد إغلاق VS Code ، يبدو أن PowerShell يرفض الفتح بشكل موثوق.

يمكنك تشغيل PowerShell Core من cmd.exe ورؤية رسالة خطأ.

عندما أحاول فتح PWSH من CMD عند المطالبة ، يبدأ PowerShell بشكل جيد. حتى مع فتح جلسة PowerShell هذه ، تؤدي محاولة فتحها من رمز شريط المهام إلى عدم فتحها. حاولت أيضًا كتابة PWSH في شريط عناوين Explorer والحصول على نفس النتيجة no-open.

من خلال عدم الفتح ، هذا ما يحدث. تنبثق نافذة تحتوي على معلومات العنوان:
""
PowerShell 6.2.0
حقوق النشر (c) Microsoft Corporation. كل الحقوق محفوظة.

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λ ';

@ انتاريس شكرا! هل الريبو الخاص بك مستمر؟ هل يمكنك إعادة الشراء باستخدام أحدث إصدار من 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 ، ستتم كتابة ملف التفريغ مع معلومات الخطأ التفصيلية إلى المجلد المحدد.

تضمين التغريدة

تمكنت من إطلاق هذه التجربة هذا الصباح. إعادة تشغيل جديدة لجهاز الكمبيوتر المحمول الخاص بي. في المرة الأولى التي فتحت فيها 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. في هذه الحالة ، أظن أن الإصدار 19H1 المستخدم من Windows Insider قد يكون السبب أيضًا.
لقد قمت بنقل كود C ++ الأصلي من Windows PowerShell إلى C # باستخدام نفس مكالمات COM واستخدمت كود مصدر حزمة Windows Api لتعريفات واجهة COM.
والخبر السار هو أن هذا الرمز يعمل فقط عندما يبدأ pwsh بشكل تفاعلي وأن تسجيل قائمة jumplist يجب أن يحدث مرة واحدة فقط (هناك رمز يتحقق من ذلك ضمنيًا). ربما ينبغي علينا وضع كتلة try {} catch حولها وتسجيل الخروج فقط من تتبع مكدس الفشل؟
بشكل عام ، عندما قمت بذلك ، كان عليّ نقل الكود الكامل. Net الخاص بحزمة Windows Api Pack إلى .Net Core وتعديله للسماح بدخول سريع مع الارتفاع. قبل أسبوعين ، أضافت WPF الكود المصدري لـ JumpList ومع العلاقات العامة للسماح برفع jumplist يمكننا تأجيل الكثير من العمل إلى بضعة أسطر فقط ، ولكن في النهاية أعتقد أنها مشكلة.

bergmeister هل أنت على استعداد لتولي هذا العمل؟ رجاء :)

يمكنني أن أحاول ، سوف تحتاج واجهة WPF API إلى شيء مثل معلمة منطقية مضافة (افتراضيا إلى خطأ) لجعل إدخال jumplist يفتح التطبيق في الوضع المرتفع. سيعتمد ذلك على مدى مرونة شباب WPF من حيث الرغبة في قبول تغيير واجهة برمجة التطبيقات ومدى صعوبة دمج العلاقات العامة ولكن أعتقد أنه سيكون سباق مع الزمن لأن. 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 ، لكنها تغلق بسرعة كبيرة ... لكنني حصلت عليها:

كما أنني لا أجرب هذا بنفس القدر عند تشغيل "كمسؤول" ، كما يذكر Antaris ، لا يزال يحدث أحيانًا.

يمكننا الحصول على مزيد من المعلومات مع بناء التصحيح (نتجاهل الأخطاء في بناء الإصدار في الكود!)

@ SteveL-MSFT لقد فتحت مقترح واجهة برمجة التطبيقات في WPF للحصول على تسجيل الخروج أولاً (التغيير المقترح ليس منقطعًا ، لذا يجب أن يكون جيدًا) وقمت بتضمين بعض تفاصيل التنفيذ منخفضة المستوى. لم ألقي نظرة على كود 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. يمكن أن يأتي الإصلاح المناسب لاحقًا.

@ SteveL-MSFT هل أنت متأكد من إمكانية اكتشاف استثناء CLR فادح؟ سيكون التحقق من الإصلاح صعبًا نظرًا لعدم وجود بيئة يمكنني فيها إعادة إنتاج هذا. يمكنني محاولة إنشاء إصدار من PowerShell باستخدام هذا الإصلاح وتحميله هنا حتى يتمكن الأشخاص في هذه المشكلة من اختباره؟

bergmeister لا أستطيع أن أعبر عن هذا بنفسي. أعتقد أن الخيار الأفضل قد يكون كما تقترح لبناء موقع خاص واطلب من شخص يمكنه إعادة بروروه لتجربته.

أرى أننا نتجاهل رموز الإرجاع في الشفرة التي يمكن أن تكون سيئة.

[عدل] تجاهل تعليقي السابق ، على الرغم من أن سمات [PreserveSig] خاطئة في عدة أماكن ، أثناء إجراء العلاقات العامة لإصلاحها ، لاحظت أنها كانت خاطئة فقط في طرق الواجهة التي لم تتصل بها.

لدي التغييرات هنا إذا كنت تريد علاقات عامة على أي حال ، لكن لا ينبغي أن يكون مصدر الأعطال.

weltkante مثير للاهتمام ، لقد أخذت تعريفات الواجهة من حزمة Windows API الأصلية (انظر على سبيل المثال هنا ) ولم أكن على علم بذلك. أنا لست خبيراً في هذا المجال ولكن إذا كنت تعتقد أن التغييرات التي أجريتها تجعله أفضل ، فيرجى إرسال بيان عام.

Antarisjlourosmsftrncscpmcgrath
في PR # 9896 ، أضفت صيدًا عالميًا حوله وأضفت التسجيل للحصول على مزيد من المعلومات.
يرجى تنزيل MSI من الإصدار PowerShell-CI-windows لهذا الإصدار PR. إذا لم تكن معتادًا على النظام ، فما عليك سوى استخدام الرابط المباشر للبناء هنا والنقر فوق الزر الموجود أعلى اليمين ، ثم النقر فوق Artifacts ثم القائمة الفرعية artifacts . سيؤدي هذا إلى تنزيل ملف مضغوط وهناك MSI ، وهو إصدار مخصص من PowerShell 7 من أحدث التزام في الإصدار الرئيسي.

يرجى الإبلاغ عما إذا تم إصلاحه وإذا لم يكن كذلك ، فيرجى تقديم رسائل السجل التي تمت طباعتها إلى وحدة تحكم PowerShell. سيتم تسجيل الخروج من جميع المراحل التي يمر بها الكود. إذا رأيت رسالة بالتنسيق Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. فالرجاء إخبارنا لأن ذلك يعني أن بيان catch كان قادرًا على اكتشاف خطأ CLR الفادح (وهو ما أشك في الوقت الحالي).
هذا مجرد اختبار بناء وليس مخصصًا لأي استخدام مدعوم.
تحديث (19 يونيو): لقد قمت بتحديث الرابط إلى إصدار أحدث يجب أن يلتقط الاستثناءات داخل بيان Task.Run كما كان من قبل لا يزال من الممكن تسريبه.

bergmeister لقد قمت بتثبيت Preview7 MSI وسأعاود الاتصال بك بينما أحاول إعادة إنشاء المشكلة وتشغيلها لبضعة أيام كصدفة رئيسية 👍

أرى أننا نتجاهل رموز الإرجاع في الشفرة التي يمكن أن تكون سيئة.

iSazonov أين ترى ذلك؟ لقد أجريت للتو مراجعة لإعلانات واجهة COM بالإضافة إلى طريقة الاستدعاء CreateElevatedEntry ولم أتمكن من العثور على أي خطأ واضح ، على الأقل في الأساليب المستخدمة بالفعل. يبدو أن جميع الطرق التي تعلن PreserveSig تقوم بفحص رموز الإرجاع الخاصة بها (الطرق التي تُرجع باطلة ولا تعلن PreserveSig يتم فحص كود الإرجاع الخاص بها بواسطة طبقة interop).

على أي حال ، لا يمكن أن يؤدي عدم التحقق من رموز الإرجاع إلى AccessViolationException في coreclr. إذا كان Stacktrace من anmenaga أعلاه يمثل المشكلة ، فقد يكون خطأ آخر في طبقة توافق coreclr (كان هناك عدد قليل بالفعل)

إذا لم يؤد تحقيقك إلى أي مكان ، فقد يكون من المفيد وجود شخص من coreclr يلقي نظرة على مكب النفايات. إن وجود stacktrace في كود coreclr الداخلي لا يشبه كثيرًا استدعاء إعلانات interop مشفرة بشكل خاطئ. على وجه الخصوص ، عندما يكون في فئة المساعد 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.

@ انتاريس شكرا. ملاحظة: إذا رأيت رسالة بالتنسيق Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. فالرجاء إخبارنا لأن هذا يعني أن بيان catch كان قادرًا على اكتشاف خطأ CLR الفادح (وهو ما أشك في الوقت الحالي).
في غضون ذلك ، أظن أن هذا الخطأ يحدث بدلاً من الأجهزة ذات مواصفات الأجهزة المختلفة ، لقد سئمت من نواة 1 و 4 و 16 وحدة المعالجة المركزية. يمكن لأي شخص مشاركة التفاصيل؟

bergmeister لم أتمكن من تكرار المشكلة في الأيام القليلة الماضية. سأستمر في ذلك ، حيث أستخدم PowerShell باستمرار.

أنا أيضا لم أواجه أي استثناءات.

كمرجع ، جهاز المواصفات الخاص بي هو:
ديل اكس بي اس 15 9570
انتل كور i7-8750H - 6 كور
32 جيجا رام

هذا جيد ولكن هل رأيت يومًا رسالة في وحدة التحكم تقول شيئًا مثل
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ؟
فقط إذا كنت قد رأيت ذلك ، فسيكون هذا دليلًا على أنه يمكن اكتشاف خطأ CLR الفادح بنجاح.

يمكنني إعادة إنتاج هذا الخطأ في كل مرة إذا حاولت تشغيل PowerShell. سوف أصف في سيناريوهين مختلفين ، في الأول ، إنه يعمل بدون أي مشاكل من ناحية أخرى مع الثاني لا.
إذا لزم الأمر يمكنني تقديم المزيد من السجلات أو المخرجات.

أجهزتي:

لينوفو Y520
Intel I7 7700HQ (2.8 جيجا هرتز)
16 جيجا رام
Samsung 512 970Pro SSD
قرص صلب ويسترن ديجيتال WD10SPCX سعة 1 تيرابايت
Nvidia 1050TI GPU 4 جيجابايت

برنامجي:

نظام التشغيل:
M $ Windows 10 - الإصدار 1903 - OsBuild 18917.1000

كود VS:
الإصدار: 1.36.0-insider (إعداد النظام)
الالتزام: 68a7e5bc437b38d0281df0756997a25da2a2900c
التاريخ: 2019-06-18 T18: 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

بوويرشيل:
PSVersionTable دولار

قيمة الاسم
---- -----
PSVersion 7.0.0-preview.1
PSEdition الأساسية
معاينة GitCommitId 7.0.0
نظام التشغيل Microsoft Windows 10.0.18917
منصة Win32NT
PSComp CompatibleVersions {1.0، 2.0، 3.0، 4.0…}
PSRemotingProtocolVersion 2.3.1
الإصدار 1.1.0.1
الإصدار 3.0 من WSManStack

السيناريوهات:

السيناريو 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 + <> ج.ب__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)" ، أنا لا أستخدم بايثون كثيرًا. نظرًا لأنك تقول أنه يمكنك دائمًا إعادة الإنتاج ، يرجى قراءة تعليقي أدناه وتثبيت الإصدار المخصص والرجاء الإبلاغ عما إذا كان يعمل على إصلاحه:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

usta هل يمكنك من فضلك وصف ما تعنيه بـ "pipenv (virtualenv)" ، أنا لا أستخدم بايثون كثيرًا. نظرًا لأنك تقول أنه يمكنك دائمًا إعادة الإنتاج ، يرجى قراءة تعليقي أدناه وتثبيت الإصدار المخصص والرجاء الإبلاغ عما إذا كان يعمل على إصلاحه:
# 9295 (تعليق)
تضمين التغريدة
يبدو أن هذا الخطأ قد أصلح هذا الخطأ (إذا واجهت نفس المشكلة فسوف أذكرها هنا) شكرًا

لا يمكنني إعادة إنتاجه باستخدام التصميم المخصص ، ولكنه كان نادرًا جدًا مع 7 معاينة 1 ، ومع ذلك ، فإن 6.2 تقوم بذلك بشكل منتظم. قد يكون هناك بعض الفائدة في تطبيق التصحيح على إصدار مخصص من 6.2 ، أو سلسلة من الإصدارات من 6.2. مجرد إضافة التصحيح / المحاولة / الالتقاط قد يغير شيئًا مثل قفل المورد المرتبط بالتوقيت أو شيء من هذا القبيل.

سم مكعب @ TravisEz13adityapatwardhan يجب علينا النظر في اتخاذ تغيرbergmeister الصورة إلى 6.2.2

bergmeister هل يمكننا إعادة فتح هذا الخطأ من فضلك؟
لأنني واجهت نفس الخطأ اليوم مرة أخرى (مع الخطأ الذي ذكرته (الإصدار المخصص))
(أو ربما مختلفة)

GetStartupInfo
CoCreateInstance
قائمة البداية
SetValue
ارتكب
CoCreateInstance
AddObject
خطأ CLR داخلي. (0x80131506)
في Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
في Microsoft.PowerShell.ConsoleHost + <> ج.ب__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 ()

ملاحظة C: \ Windows \ System32> $ PSVersionTable

قيمة الاسم
---- -----
PSVersion 7.0.0- المعاينة 2.25651
PSEdition الأساسية
GitCommitId 7.0.0 معاينة 2.25651
نظام التشغيل Microsoft Windows 10.0.18922
منصة Win32NT
PSComp CompatibleVersions {1.0، 2.0، 3.0، 4.0…}
PSRemotingProtocolVersion 2.3.1
الإصدار 1.1.0.1
الإصدار 3.0 من WSManStack

usta نعم ، أوافق ، يجب علينا إعادة الفتح (لا أمتلك الحقوق على الرغم من ذلك ولكنني AddObject ليس آخر سطر قبل الانهيار ، أخبرنا برغم ذلك ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL- MSFTiSazonov هذا يعني أنه على الرغم من التقارير الإيجابية الأولية التي تفيد بأن PR # 9928 غير قادر على اكتشاف خطأ CLR الفادح الذي تم الإبلاغ عنه عدة مرات (أبلغت جميع تقارير الأخطاء عن نفس الخطأ). في حين أنه لا يزال هناك بعض القيمة في إجراء عملية صيد عالمية لشيء غير ضروري ، إلا أن المشكلة لا تزال قائمة ... مع المعلومات الإضافية ، يمكنني أن أحاول معرفة ما إذا كان بإمكاننا الترميز بشكل دفاعي لتجنب الوصول إلى هذه النقطة حيث هذا تحدث المشكلة (التي أظن أنها خطأ في coreclr نفسها ، هل من المفيد فتح مشكلة هناك؟) بخلاف ذلك ، لا يمكنني التفكير إلا في تعطيل هذه الميزة عبر متغير بيئة على سبيل المثال (أو تخزين بعض المعلومات إذا تم ملء قائمة jumplist مرة واحدة بالفعل لأنها استمرت بعد ذلك ، ولست متأكدًا من استمرارها بعد تحديثات Windows على الرغم من ...) اسمح لي أن أعرف ما أنت فكر / تفضل.
في ملاحظة ذات صلة ، فتحت المشكلة التالية والعلاقات العامة في WPF لإضافة واجهات برمجة التطبيقات المطلوبة لتبسيط الكود / المسؤولية بشكل جذري في هذا الريبو من الآن فصاعدًا ولكن حتى الآن لم تتم مراجعة العلاقات العامة وتم وضع علامة على المشكلة بـ .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

bergmeister الآن حاولت مرارًا وتكرارًا إعادة إنتاج نفس الخطأ.
في النهاية ، قد أعيد إنتاجه ولكن هذه المرة أعطي سجل anohter:

GetStartupInfo
CoCreateInstance
قائمة البداية
SetValue
ارتكب
CoCreateInstance
AddObject
استثناء 'System.Runtime.InteropServices.InvalidComObjectException: لا يمكن استخدام كائن COM الذي تم فصله عن RCW الأساسي.
في System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc و IntPtr itfMT و IntPtr classMT و Int32 flags)
في Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
في Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (عنوان السلسلة)
في Microsoft.PowerShell.ConsoleHost. <> ج.b__4_0 () 'مع تتبع المكدس في System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc و IntPtr itfMT و IntPtr classMT و Int32 flags)
في Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
في Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (عنوان السلسلة)
في Microsoft.PowerShell.ConsoleHost. <> ج.تم القبض على b__4_0 () بنجاح.
ملاحظة C: \ Users \ usta>

إذا لزم الأمر ، سأكون سعيدًا باختبار بنية أخرى أو محاولة توفير سجلات أخرى (قد تحتاج إلى التغلب على هذا الخطأ)

تضمين التغريدة
أنا لست حتى مبرمجًا للتكنولوجيا ولكن لمجرد الفضول ألا يحتاج هذا السطر أيضًا إلى فحص إضافي قبل المرور إلى 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 وستطرح استثناءً)

msftrncs لا أعرف أي واجهة برمجة تطبيقات مدارة تعرض قراءة jumplists ، لذلك أظن أن واجهة برمجة التطبيقات الأصلية لا تدعمها حتى ، لكنني لم أتحقق منها. بأي شكل من الأشكال ، مجرد التحقق من الوجود أمر خاطئ ، فقد يتسبب في أن تصبح قوائم jumplists قديمة إذا تغيرت إحدى خصائصها.

في كلتا الحالتين ، إذا لم تتمكن من حل المشكلة هنا (وأنا أشك بجدية في أن إضافة try / catch لن تعمل ذعر coreclr ولا فكرة جيدة) ، فمن المحتمل أن تثير مشكلة مع coreclr لمزيد من الفحص. لديك تفريغ لفحصه بعد كل شيء. يبدو السيناريو في التفريغ بالتأكيد وكأنه خطأ كوريكلر بالنسبة لي. (انظر تعليقي أعلاه لمعرفة ما يحدث في ملف التفريغ.)

لقد فتحت مشكلة بكل التفاصيل في CoreClr repo ، ربما يمكنهم مساعدتنا. لقد ألقيت نظرة على الكود الخاص بنا مرة أخرى ولا توجد طريقة دفاعية أخرى للاستعلام عن واجهة برمجة التطبيقات إذا تم إنشاء قائمة jumplist بالفعل ، فنحن نحصل فقط على الحد الأقصى من الفتحات المتاحة ونعود مبكرًا إذا لم تكن هناك مساحة كافية لـ jumplist ، كل ما يمكننا فعله هو تخزين jumplist داخليًا مؤقتًا أو الحصول على شيء مثل علامة الميزة لتخطي رمز إنشاء jumplist الإشكالي (بمجرد إنشاء إدخال jumplist ، يستمر).
https://github.com/dotnet/coreclr/issues/25502

bergmeister لقد جربت أحدث إصدار يومي ويبدو أنه في هذا الإصدار لم أتمكن من إعادة إنتاج الخطأ.
سواء تم إصلاحه أو ذهب سبب هذا الخطأ.

ملاحظة C: \ Users \ usta> echo $ PSVersionTable

قيمة الاسم
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition الأساسية
GitCommitId 7.0.0-dailypreview2.26796
نظام التشغيل Microsoft Windows 10.0.18922
منصة Win32NT
PSComp CompatibleVersions {1.0، 2.0، 3.0، 4.0…}
PSRemotingProtocolVersion 2.3.1
الإصدار 1.1.0.1
الإصدار 3.0 من WSManStack

الجميع: قام فريق CoreClr بالتحقيق في المشكلة والمشكلة هي أن واجهات برمجة تطبيقات COM التي يتم استدعاؤها هي STA فقط (لا يزال PS Core يعمل حاليًا في MTA حتى يتم حل # 7216) ولم يقدم coreclr أي تحذيرات / أخطاء. لذلك قمت بدفع التغييرات لإنشاء JumpList في مؤشر ترابط STA ، والذي نأمل أن يكون هو الحل النهائي.
الرجاء إعادة اختبار مع أحدث بناء العلاقات العامة # 9896 وتقديم التغذية الراجعة

الجميع: تم إرجاع الإصلاح الخاص بهذه المشكلة إلى الإصدار الأخير من 6.2.2 ، يرجى التحديث وتقديم الملاحظات إذا تم إصلاحه. سيتعين على مستخدمي المعاينة انتظار 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
سم مكعبmsftrncsustaAntariscpmcgrathjlouros

: tada: تمت معالجة v7.0.0-preview.2 .: tada:

روابط مفيدة:

• ملاحظات الإصدار

: tada: تمت معالجة v7.0.0-preview.2 .: tada:

روابط مفيدة:

• ملاحظات الإصدار