WriteFile() returns 1, but writes 0 bytes

[sgomon]

I am using WriteFile() to write to a serial port on an embedded CE device
without overlapping. Very intermittantly, WriteFile() will return 0 in
lpNumberOfBytesWritten, but the function returns 1 (Success). GetLastError()
will return 0 when called right after WriteFile(). Most of the time it works
as expected. I can run the same app on the same data many times in a row
successfully between failures.

Why would it return 1, but write zero bytes?

[<ctacke/>]

It's perfectly valid to successfully write nothing - you're sure that you've
told it that the number of bytes to write is > 0 (you code logic doesn't
allow a send of 0 bytes)?

-Chris

Post by sgomon
I am using WriteFile() to write to a serial port on an embedded CE device
without overlapping. Very intermittantly, WriteFile() will return 0 in
lpNumberOfBytesWritten, but the function returns 1 (Success).
GetLastError()
will return 0 when called right after WriteFile(). Most of the time it works
as expected. I can run the same app on the same data many times in a row
successfully between failures.
Why would it return 1, but write zero bytes?

[sgomon]

I've checked this. It is supposed to write 53 bytes from a valid buffer.

Post by <ctacke/>
It's perfectly valid to successfully write nothing - you're sure that you've
told it that the number of bytes to write is > 0 (you code logic doesn't
allow a send of 0 bytes)?
-Chris

Post by sgomon
I am using WriteFile() to write to a serial port on an embedded CE device
without overlapping. Very intermittantly, WriteFile() will return 0 in
lpNumberOfBytesWritten, but the function returns 1 (Success).
GetLastError()
will return 0 when called right after WriteFile(). Most of the time it works
as expected. I can run the same app on the same data many times in a row
successfully between failures.
Why would it return 1, but write zero bytes?

[Bruce Eitman (eMVP)]

You may need to contact the OEM to find the answer to this.

[Paul G. Tobey [eMVP]]

Perhaps you are sending data a lot faster than the serial port can send data
to the other device at the end of the serial cable. Or perhaps that device
is using handshaking to stop you from sending. At some point, your send
buffer is going to fill up and the driver is going to tell you that your
write didn't send anything. If it were me, I'd return an error in that
case, but the driver can decide what it wants to do.

Paul T.

Post by Bruce Eitman (eMVP)
You may need to contact the OEM to find the answer to this.
--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net
Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

[Steve Maillet (eMVP)]

Actually the driver doesn't get to "decide" the appropriate thing to do in
that case is to indicate a timeout. If the driver does not indicate an error
in this case - it's a bug in the driver. If you were making up your own
driver then you can do whatever you want but a serial driver has specific
requirements for it to work correctly in the system.

[sgomon]

We are using this to upgrade fimware on a printer controller board from the
CE board. Our firmware programmer said that when this happens, the printer
controller board is waiting for data. We do try to resend the data with time
delays between each attempt, but all successive tries result in a return of 1
with zero bytes written.

Post by Steve Maillet (eMVP)
Actually the driver doesn't get to "decide" the appropriate thing to do in
that case is to indicate a timeout. If the driver does not indicate an error
in this case - it's a bug in the driver. If you were making up your own
driver then you can do whatever you want but a serial driver has specific
requirements for it to work correctly in the system.
--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

[sgomon]

One more detail, I have tried closing the port then reopening it when this
happens, but it did not fix the problem.

Post by Steve Maillet (eMVP)
Actually the driver doesn't get to "decide" the appropriate thing to do in
that case is to indicate a timeout. If the driver does not indicate an error
in this case - it's a bug in the driver. If you were making up your own
driver then you can do whatever you want but a serial driver has specific
requirements for it to work correctly in the system.
--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com