Помогите найти, где программа начинает жрать память и процессорное время.
Я написал Windows Service, который опрашивает через Serial Port одно устройство, и пишет данные с него в лог.

Serial Port этот виртуальный, то есть эмулируется драйвером устройства типа Serial Port over Ethernet. В следствие багов этого драйвера порт иногда исчезал. Из-за этого моя программа регулярно сыпалась на моментах ввода/вывода на порту.

Я этот баг исправил, думаю, не самым красивым образом - пересоздаю экземпляр порта, не имея возможности удалить старый экземпляр.

Вот такой код:



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

Как показывает практика: как только я специально удаляю этот порт, служба начинает хавать под 100% процессорного времени и неистово начинает потреблять память.

Кто может подсказать, где ошибка?

Если по некоторым методам есть вопросы, спрашивайте.

для начала сделай так

Примечание. 
Всегда вызывайте метод Dispose перед освобождением последней ссылки на объект Component. В противном случае используемые им ресурсы не будут освобождены до тех пор, пока сборщик мусора не вызовет относящийся к объекту Component метод Finalize.
 
ps: если класс имеет интерфейс IDisposeble, то желательно(или необходимо) использовать Dispose.

Это сообщение отредактировал(а) uranpro - 11.2.2010, 16:45

Ну скорее всего там постоянно валятся исключения на этом месте:

Старый порт не закрыт, поэтому нельзя его открыть ещё раз.
Пройдись отладчиком и узнаешь точно.

Как решить проблему uranpro уже написал. 

msdn> На практике рекомендуется после вызова метода Close подождать некоторое время, прежде чем вызывать метод Open, поскольку порт не всегда закрывается мгновенно.
=)

  
Поймите же меня правильно: поскольку порт уже исчез из системы, любые обращения к его свойствам и методам тупо ведут к исключениям. Что и вынуждает меня юзать такой радикальный метод, как забыть о старом объекте и создать новый.

Естественно, Close порождает эксепшен, Dispose порождает эксепшен, да что угодно порождает эксепшен, если объект исчез таким нехорошим образом.

Насчет освобождения ивентов - завтра попробую, но что-то мне кажется, что это не решит проблему.

Freak_FB, вызывай Dispose в блоке finally, внутри которого будет try{b.dispose();}catch(){/* eat all errors*/} ....

Активный гуглинг показал, что проблема в интернетах встречалась и ранее, и то, что в данной ситуации начинает активно увеличиваться занимаемая память и время работы ЦП, - вполне закономерно, исходя из способа работы класса SerialPort.

Если кому интересно: обсуждение данной проблемы на микрософтовском форуме.

Проблему решил аварийной остановкой службы. И автовосстановление в настройках службы.