Grief with a serial port

[ThermoSight]

Hi.
I am working with VS2010 C++, Windows 7 Pro, and a serial device.

The C++ app is unaffected by cycling power on the serial device. However, cycling power on the PC (Windows 7 Pro) causes the C++ app to fail (that is, when power is restored to the PC and Windows is rebooted, the app can no longer 'talk' to the device).

It is important to note that a C# tool can talk to the device regardless of power cycle of either the serial device or the PC. It just works!

Indeed, when the app fails, using the tool to 'talk' to the serial device restores the ability of the C++ app to talk to the device.

That suggests to me that the C# tool is doing something to the port (COM1).

I have determined by visual inspection that when it's failing, the DCB content is identical to that when it's working. I create a DCB, download the current DCB state via GetCommState, modify the DCB to fit my requirements (38.4, 8, n, 1), then SetCommState. I now also follow the SetCommState with another GetCommState to verify that the DCB is set as intended.

Also, I now, in my desperation, issue a call to ClearCommError immediately after the call to CreateFile, thinking that the port might be coming up in some error state after a power cycle. No help there.

After all of that, I issue a single character command to the device via the asynchronous WriteFile & GetLastError & WaitForSingleObject & GetOverlappedResult sequence. Of course, all indications are that all went well.

But the following ReadOverlapped fails unless the C# tool has been used to 'talk' to the device first.

So, bottom line,
a) I have observed the DCB with the debugger, and determined that it is good (or at least identical to the DCB content in effect when the app is working)

b) there are NO error indicators returned throughout the write and read process but the C++ app never sees any reply from the device (unless the C# tool has run at least once)

c) I have determined that when it IS running, the C++ app is indeed writing the correct command to the serial device and reading the device's reply correctly.

Any suggestions as to another item I might check ?

thanks

bill