EnterpriseLibrary Error

Question

Otrzymuję zgłoszenia o rzadkim i sporadycznym błędzie w naszym środowisku na żywo. Nie udało mi się go odtworzyć, a sam błąd jest drobną zagadką. Dodajmy do tego, że wydaje się, że jest coś związanego z śledzeniem biblioteki Enterprise (używamy wersji 5.0) - w sumie trochę bólu. Dzieje się tak na Windows Sever 2008, aplikacja działa na .Net Framework 4.0 (WPF).

Komunikat o błędzie, a stos ślad obserwacji:

ArgumentNullException: Value cannot be null. Parameter name: category 

<StackTrace> 
    Server stack trace: 
    at Microsoft.Practices.EnterpriseLibrary.Logging.LogEntry.BuildCategoriesCollection(String category) 
    at Microsoft.Practices.EnterpriseLibrary.Logging.Tracer.WriteTraceMessage(String message, String entryTitle, TraceEventType eventType) 
    at Microsoft.Practices.EnterpriseLibrary.Logging.Tracer.WriteTraceEndMessage(String entryTitle) 
    at Microsoft.Practices.EnterpriseLibrary.Logging.Tracer.Dispose() 
    at TestApplication.ViewModelTest.&lt;UpdateUsers&gt;d__1a.MoveNext() 

    Exception rethrown at [0]: 
    at System.Runtime.CompilerServices.AsyncVoidMethodBuilder.&lt;SetException&gt;b__1(Object state) 
    at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state) 
    at System.Threading.ExecutionContext.runTryCode(Object userData) 
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) 
    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) 
    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx) 
    at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() 
    at System.Threading.ThreadPoolWorkQueue.Dispatch() 
    at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() 
</StackTrace> 

Czy ktoś może rzucić jakieś światło na to, co może być przyczyną?

EDYTOWANIE: Nie modyfikuję LogEntry.BuildCategoriesCollection. Dane wejściowe do metody BuildCategoriesCollection (kategoria String) mają wartość null.

Sposób UpdateUsers jest następujący:

async void UpdateUsers() 
{ 
    Processing = true; 

    using (traceMgr.StartTrace("Trace")) 
     using (var engine = new EngineClient()) 
     { 
      Users = new List<UserMasterDataModel> { _blankUser }; 
      var users = await engine.GetPossibleTagsTask(SelectedOutcomeId, _queue.SystemCd, _queue.QueueCd); 
      Users.AddRange(users); 
     } 

    if (SelectedUser != _blankUser) 
    { 
     // If null user selected then initialize to the case's tag, otherwise try to find the previously selected UserName 
     var userNameToFind = SelectedUser == null ? _details.TagTo : SelectedUser.UserName; 
     SelectedUser = Users.FirstOrDefault(user => user.UserName == userNameToFind) ?? _blankUser; 

     OnPropertyChanged("SelectedUser"); 
    } 
} 

Answer 1

Problem ten wydaje się być znany bug na e-lib w poprzednich wersjach też.

Znany jako: Nieobsługiwany wyjątek podczas korzystania z rejestrowania AB z wielu wątków.

"Podstawową kwestią jest to, że w RTM .NET 2.0 stos operacji macierzystego wątku został udostępniony jego dzieciom, jeśli taki stos istniał przed utworzeniem dzieci."

Czytaj więcej tutaj: http://entlib.codeplex.com/workitem/9592

Trudno sugerować ogólne rozwiązanie tego jak to bardzo zależy od architektury aplikacji.