集合上的奇怪異常

當我嘗試添加/插入/刪除到集合（或任何更改集合的操作）時，我會得到以下異常。集合被初始化，並且插入的項目不是null，並且與集合T的類型相同。集合上的奇怪異常

任何人都可以爲我提供線索，爲什麼會發生這種情況？

運行時遇到致命錯誤。該錯誤的地址是0x60f41744，線程0x231c。錯誤代碼是0x80131623。
此錯誤可能是CLR或用戶代碼的不安全或不可驗證部分中的錯誤。此錯誤的常見來源包括COM-interop或PInvoke的用戶編組錯誤，這可能會破壞堆棧。

更新：該集合是一個ObservableCollection，我設法瞭解它發生在已更改集合的通知部分。

這發生在具有TaskScheduler.FromCurrentSynchronizationContext()選項的任務內的UI線程上。

奇怪的是，如果我刪除此（TaskScheduler.FromCurrentSynchronizationContext()）選項添加/插入/刪除操作，似乎都工作良好。

來源

2013-01-06 shahar eldad

錯誤代碼是0x80131623

這是一個非常特殊的錯誤代碼，COR_E_FAILFAST。只有一種方法可以生成它，有人稱爲Environment.FailFast（）。

很明顯，挑戰在於找出哪些代碼叫做那個。首先查看Windows應用程序事件日誌，無論傳遞給FailFast（）的字符串是什麼，都應該有關於它的消息，它提供了調用的主要原因。

通過System.Environment.FailFast（字符串消息）的應用所請求的過程終止。
在System.Environment.FailFast（System.String）
在System.Windows.WeakEventManager.DeliverEventToList（System.Object的，System.EventArgs，ListenerList）
在System.Windows.WeakEventManager.DeliverEvent（System.Object的，系統.EventArgs）

是的，該代碼中有一個Assert（）。我只會發布我在參考資源中看到的內容，我對代碼不夠了解，看看你做錯了什麼。除此之外，線程無疑是觸發這類問題的好方法，ObservableCollection完全是線程不安全的並且必須由鎖保護。

// if the event isn't handled, something is seriously wrong. This 
    // means a listener registered to receive the event, but refused to 
    // handle it when it was delivered. Such a listener is coded incorrectly. 
    if (!handled) 
    { 
     Invariant.Assert(handled, 
        SR.Get(SRID.ListenerDidNotHandleEvent), 
        SR.Get(SRID.ListenerDidNotHandleEventDetail, iwel.GetType(), managerType)); 
    }

來源

2013-01-06 13:52:09

嗯，我在事件查看器中發現了一個調用FailFast：Framework版本：v4.0.30319 描述：應用程序通過System.Environment.FailFast（字符串消息）請求進程終止。在System.Windows.WeakEventManager.DeliverEventToList（System.Object，System.EventArgs，ListenerList）上的System.Environment.FailFast（System.String） System.Windows.WeakEventManager.DeliverEvent（System.Object，System .EventArgs）很明顯是來自ObservableCollection的通知，但爲什麼？爲什麼只在UI線程上發生？ –

對不起 - 但評論中的無回車鍵很難:) –

回答更新。 –

-2

內存不足，運行損壞。

這是一個致命的錯誤 - 因此它不是一個.NET級別的錯誤，它指出了無論出於什麼原因的一些內存損壞，就像它說的那樣。可能是內存不足，電源供應不良，或者是非託管部件中的程序錯誤導致內存損壞。或運行時錯誤（JIT級別，即處理彙編程序級別或WPF /本地區域的部分），但我以某種方式懷疑這一點。

順便說一下，發佈錯誤描述時不太聰明 - 沒有 - ah - 錯誤的類型。

來源

2013-01-06 11:38:32 TomTom

我已更新我的問題。對不起，但我不接受它只是一個幕後的錯誤。我做錯了什麼，我想知道你從我的更新中可以看到什麼。 –

不是。抱歉。 PER定義 - 這不能是你的錯誤。你做的任何事情都應該導致.NET級別的異常。沒有損壞的記憶。這是託管語言的保證。無論你做什麼，它都必須拋出異常。你有什麼是一個錯誤 - 損壞的內存，這是不可能產生（理論上）託管代碼。我會在谷歌尋找錯誤代碼，並玩耍，應用補丁，向微軟提交錯誤。 – TomTom

不管你在託管代碼中只允許導致這個錯誤。沒有。 – TomTom

集合上的奇怪異常

回答

相關問題