Вызывает сомнение строка
cto.WriteTotalTimeoutMultiplier = 2*CBR_9600/dwBaudRate;

CBR_9600 определена как 9600, поэтому если скорость dwBaudRate больше,чем 19200, то WriteTotalTimeoutMultiplier = 0, а константа WriteTotalTimeoutConstant вообще не определена.

Хотя факт, что модем возвращает эхо, вроде говорит о том, что он данные получил. А в терминале-то модем откликается на ATZ\r? С параметрами DCB,контролем четности и т.д. все в порядке?

Для работы с COM-портами есть неплохой класс у PJ Naughter:

http://www.naughter.com/serialport.html

Из своего опыта: я использую WaitCommEvent для отслеживания изменения состояния CONNECT в отдельном потоке, запись/чтение делаю также в отдельном потоке, порт открываю в "Nonoverlapped" режиме,
регулируя временные характеристики протокола установкой констант COMMTIMEOUTS. Такой способ существенно (до банального) упрощает текст программы, реализующей собственно протокол, без какой-либо потери функциональности, ведь по сути приведенный однопоточный код все равно блокирует поток,
ожидая завершения каждой операции, но при этом код становится существенно сложнее. К примеру, задав нужные значения констант, достаточно сделать ReadFile и получить управление либо при успешном чтении, либо по истечении времени, определенного параметрами констант. Что касается записи, там это вообще некритично за счет многоуровневого буферирования (в том числе и в самом модеме). OVERLAPPED же режим был бы оправдан, если передающий или принимающий поток могли бы делать нечто полезное после начала операции и вплоть до ее завершения.

Евгений.