Постановка в очередь обновлений ObservableCollection

Вы проверили, является ли результат FirstOrDefault null? Это может произойти, если в коллекции нет элемента с заданным id.

Например:

var element = this.FirstOrDefault(p => p.ID == id);
if (element != null) {
    // Do something with element.Number.
}

Или вы можете просто позвонить First и посмотреть, получите ли вы InvalidOperationException.

--- ИЗМЕНИТЬ ---

Из вашего комментария я вижу, что вы, похоже, одновременно обращаетесь к одному и тому же ObservableCollection из нескольких потоков. Если это так, вам необходимо защитить общую структуру данных с помощью блокировки. Вполне возможно, что один поток начинает вставлять новый элемент как раз в тот момент, когда другой его ищет, что приводит к разного рода неопределенному поведению. Согласно документации MSN для ObservableCollection:

"Не гарантируется, что любые члены экземпляра будут потокобезопасными."

Что касается отладки, вы можете «заморозить» другие потоки и таким образом сосредоточиться только на интересующем вас потоке без чрезмерных «прыжков». См. панель «Потоки», контекстное меню, параметры «Заморозить» и «Разморозить».

Обновление ObservableCollection — длительный процесс, по крайней мере, по сравнению с получением и обработкой событий TAPI. Это может привести к состояниям гонки, когда состояние вызова, которое должно было бы отредактировать запись вызова, не могло найти запись, поскольку оно требовало блокировки для записи/обновления коллекции до состояния вызова, которое фактически должно было бы добавить вызов. Кроме того, неправильная обработка событий TAPI в надлежащем порядке приведет к поломке конечного автомата.

Я решил реализовать упрощенный шаблон команды. События TAPI, которые раньше запускали транзакции с тяжелым состоянием производительности, добавляются в потокобезопасную, неблокирующую и наблюдаемую очередь команд. Когда команда ставится в очередь, класс очереди начинает «выполнять» (и удалять из очереди) команды в новом потоке, то есть запускает правильные состояния вызова в конечном автомате до тех пор, пока в очереди не останется команд. Если уже запущен поток удаления из очереди, новый поток не создается (многопоточность снова приведет к условиям гонки), а класс очереди блокирует повторный вход, чтобы гарантировать, что только одна команда будет выполняться в любой момент времени.

В общем, все TAPI-события (вызывающий) добавляются в очередь (клиент) в том порядке, в котором они происходят, как можно быстрее. Затем очередь передает информацию TAPI получателю, конечному автомату, выполняющему бизнес-логику, не торопясь, но следя за тем, чтобы информация обновлялась в правильном порядке.

Изменить. Начиная с .NET 4.0 вы можете использовать ConcurrentQueue (T) Class для достижения того же результата.