Столкнулся с такой проблемой:
есть приложение на фреймворке 2.0 в виде виндовс-сервиса, которое инициализирует 4 потока:
1 - слушает порт;
2 - с определенным интервалом проверяет сообщения на РОР3 сервере;
3 - с определенным интервалом читает новые задачи из таблицы задач в БД SQL 2005, при поступлении новых задач сканирует папку с длл-ками и запускает метод одной из них для выполнения нужной задачи.
4 - с определенным интервалом читает папку с длл-ками и запускает метод одной из них.

Все работало отлично на двухпроцессорном Ксеоне и на большинстве других доступных в поле зрения машинах до тех пор, пока клиент не создал копию приложения и БД на другую машину с одним двухядерным ксеоном: потоки инициализируются, но работают все, кроме третьего потока. По логам видно, что он пытается прочитать информацию о задаче из БД и на этом глохнет.

Клиент утверждает, что причина в "улучшенной многопоточности" новой тачки, фреймворк не умеет работать на таком проце... Мне кажется, что что-то намудрил при установке СКЛ или винды их специалист.

Помогите разобраться. Клиент очень нервничает :(

Спасибо за реакцию.
Самый большой прикол в том, что приложение работает на ура на всех других машинах, где пробовали его установить. Даже на той, где стоят два таких же процессора, как и на той машине, где не работает.
Потоки между собой никаким образом не взаимосвязаны.

kolobok0 amids..Самый большой прикол в том, что приложение работает на ура на всех других машинах, где пробовали его установить. Даже на той, где стоят два таких же процессора, как и на той машине, где не работает.
Потоки между собой никаким образом не взаимосвязаны.

1) обычно разное поведение на разных машинах и(или) при изменении внешних условий работы влияет на не совсем корректно построенный код. это по опыту. скажем так - я бы поставил бы это на первое место по приоритетам "где искать"...
2) не связаны у Вас явно ? А не явно ? Ведь Вы написали, что как минимум 2 потока используют файловый ввод вывод - а это уже пересечение логик. Попробуйте локализовать проблему - закоменнтируйте (или не запускайте) определённые потоки. В потоках попробуйте убрать всё то, что обращаеться к ресурсам или во внешний мир... при этом время жизни потоков постарайтесь оставить такой-же.

с уважением
(круглый)

Сделал так, как Вы написали: отключил все потоки, кроме проблемного.
Вот еще подробности:
Поток забирает из БД список задач обычным селектом:
Select id from queueMessages where (status='new') and (postTime < @when)
где @when - текущее время.
Сиквел возвращает таблицу, сервис видит, что записей больше 0 и вызывает метод другого класса, который пытается сделать селект одной из записей
Select * from queueMessages where id=40
Запрос поступает на сиквел, но на этом все заканчивается.

Спасибо всем, проблема была не в процессоре и не в ядрах, а в региональных настройках винды, сиквела и самого фреймворка.

Фреймворк получал дату из стрингового поля БД и пытался его пропарсить. Не получалось, так как формат даты не совпадает.

Осталось разобраться в региональных настройках самого фреймворка.