2012-06-08 1 views
1

У нас есть большое деловое приложение, которое работает поверх WPF и Entity Framework. Проблема в том, что у нас есть проблема в течение последних 2 недель и не может определить ее источник.Как получить дополнительную информацию из Exception (случайный случайный C# WPF)?

Исключение в настоящее время в ловушке DispatcherUnhandledException и информация, которую мы получаем от исключения (по электронной почте) заключается в следующем:

mscorlib: Value cannot be null. 
    at System.Threading.Monitor.ReliableEnter(Object obj, Boolean& lockTaken) 
    at System.Threading.Monitor.Enter(Object obj, Boolean& lockTaken) 
    at System.Data.EntityClient.EntityConnection.ChangeConnectionString(String newConnectionString) 
    at System.Data.EntityClient.EntityConnection.Dispose(Boolean disposing) 
    at System.ComponentModel.Component.Finalize() 

Исключение бросают «случайно» 4 или 5 раз в день и только от ОДНОГО из 20 + пользователей, которых мы имеем. Мы не можем решить проблему !. трассировка стека не дает много информации, и мы не можем воспроизвести проблему.

Я предполагаю, что это происходит в потоке, но я не могу определить поток, вызывающий исключение, так как у нас много фоновых рабочих и асинхронных вещей!

Итак, как я могу получить дополнительную информацию об исключении?


Edit:

Существует нет никаких InnerExceptions.

Кроме того, исключение составляет интервалы в несколько минут, а затем часы, например: 11:41, 11:46, 11:51, тогда он работает нормально до 18:03, 18:07, 18:11, тогда никакие исключения не выбрасываются. Моменты, в которых происходят эти минутные интервалы, также случайны, не связаны с какой-либо нагрузкой на серверы или сеть.

+3

Есть ли 'InnerException', который не доставляется по электронной почте? –

+0

нет, все исключенные исключения отправляются с их Внутренними Исключениями, если они есть. –

+0

У вас, вероятно, есть исключение где-то в вашем коде, который скрыт некоторым обратным вызовом в рамках.Попробуйте добавить предложения catch, которые регистрируют исключения, а затем бросают; их обратно в точки соприкосновения с WPF (например, в установках VM, в реализации команд). Кроме того, если возможно, отправьте этому клиенту соответствующие PDB и попробуйте отладить удаленно (с помощью Visual Studio Remote Debugger). –

ответ

3

Похоже, что это, вероятно, происходит как часть потока коллекции мусора. Вызов Finalize в нижней части стека - это подсказка, и тогда это, вероятно, вызывает EntityConnection.Dispose (false);

Характер проблемы не является детерминированным. Возможно, в вашей среде что-то изменилось, и теперь это происходит.

В финализаторе очень опасно обращаться к другим управляемым объектам. Похоже, что ChangeConnectionString, вероятно, пытается использовать управляемый объект в качестве блокировки, а иногда, когда он находится в потоке GC, объект уже очищен. То, что он делает это, вероятно, является ошибкой в ​​EntityConnection.

Вы должны быть в состоянии избежать этого, вызывая Dispose на своих Компонентах, вместо того, чтобы позволить Finalizer запускаться (включение их в использование блоков - отличный способ обеспечить это). Однако с помощью вызова, который у вас есть, сложно сказать о характере Компонента, который вызывает проблему.

Если вы хотите получить локальный реестр, попробуйте подклассифицировать объекты Component, которые обращаются к EntityConnections с классом, который переопределяет Finalize (например, ~ MyComponent()) и бросает в него исключение. Таким образом, вы получите крах, если GC когда-либо очистит эти объекты.

+0

У нас есть предложение 'use' во всех соединениях EF. Сейчас я делаю удаленную отладку, я никогда раньше не использовал ее, и она выглядит многообещающей. Спасибо за Ваш ответ. Я обновлю эту тему с дополнительной информацией, когда она будет доступна. –

1

Ошибка «ReliableEnter value not null» означает, что вы пытаетесь заблокировать объект, для которого установлено значение null.

Найти, где объект установлен в null.

Смежные вопросы