ТС походу объявил в проге массив, и считывает в него то что приходит с порта. и не проверяет размер, соответсвенно если пришло больше чем размер массива - пишет дальше

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

что не так в моем рассказе?

Не затирается, а Вы его затираете некорректной работой с памятью, указателями итп. В С и даже в С++ система особенно не отслеживает выходы за границы массивов, выделенной области памяти для объектов, адресуемых указателями итп. Ищите у себя где Вы затираете переменную.

Если устройство использует аппаратные сигналы DTR и/или RTS для разрешения работы, то при закрывании порта эти сигналы сбросятся и устройство ничего выдавать не будет. Так, кстати поступают телефонные модемы по умолчанию.

Я в шоке.
Где TC пишет о своём буфере???
Речь идёт о стандарном виндовском.

А вот что не так . Бывают конструкции внешних устройств, которые питаются за счет сигнальных линий СОМ-порта (т.к., в отличие от USB, питание на этот разъем не подается). К такому решению располагает уменьшение энергопотребления большинства МК (им такой мощности для питания достаточно), но отвращает, что СОМ-порт постепенно выходит из моды, исчезая из стандартных устройств ПК.

Часто потупают так - отказываются от хэндшейкинга, а освободившиеся линии DTR и RTS используют для питания. При этом напряжение на них уставливают в "противофазе", чтобы получить побольше разность потенциалов, и тогда из нее можно получить стабилизированное 5 вольт.

Закрытие СОМ-порта приведет к тому, что выставленные уровни DTR и RTS изменятся, т.к. закрытый СОМ-порт не держит своих прежних установок. А питание внешнего устройства по многим причинам прекращать бывает нежелательно. Особенно в тех случаях, когда оно работает в ждущем режиме - не постоянно посылки гонит, а лишь в случае наступления того или иного события. Вот и было бы заманчиво установить такой режим (перепрограммирование СОМ-порта без его закрытия), чтобы (временно) отказаться от приема сообщений, но сам СОМ-порт не закрывать, чтобы сохранить уровни DTR и RTS.

Всевозможные идеи (а таких можно выдвинуть много) о том, как можно организовать альтернативное питание, не взирая на полярность DTR и RTS, можете оставить при себе. Сейчас же интересует только одна вещь - возможно это сделать программным путем или невозможно. И выяснить этот вопрос хотелось бы раньше, чем брать в руки паяльник и курочить внешнее устройство.

Xenia, бывает, что и корова летает... при себе можно вообще оставить все попытки подсказать топикстартеру методы решения его проблемы, ограничившись просто советом найти и исправить ошибку в программе - ведь это очевидно все, не так ли? кстати, топикстартер и просил "временно приостановить прием" - что может быть лучшепроще закрытия порта для этого?!

Как показывает опыт работы по RS232 с различными устройствами неосознанное манипулирование с DTR и RTS очень часто приводит к полному разочарованию. И далеко не все устройства имеют 3-проводный RS232. Поэтому простое с точки зрения программиста решение - дезактивирование порта при нежелании что-либо принимать - не может быть универсальным решением. На самом деле самое простое - игнорировать и очищать буфер приема. Если это не получается - читать документацию и/или искать ошибку в собтвенном коде. Это так же как пользоваться вместо выключателя выдергиванием и вставлением вилки в розетку особенно при 1 кВт мощности.

Вы невнимательно читали его просьбу, а потому так неадекватно реагируете. Топикстартер САМ наотрез отказался закрывать СОМ-порт, вот так обосновав свой отказ:

Т.е. изначально поставил задачу так, чтобы решение не содержало закрытия порта.

Ваша правда, это я накосячил. Сегодня потрассировал внимательнее. Оказалось что я очищал буфер путем определения количества байт в нем ф-ей ClearCommError, потом читал всю эту длину одним махом в свой буфер. А когда мусора было слишком много, больше моего буфера, то соответственно терлись соседние данные. Вылечил заменой на PurgeComm.
Всем спасибо, ваши советы подтолкнули где искать ошибку.