HandyOrg/HandyControl · error
Wrote an incorrect number of bytes
Error message
Wrote an incorrect number of bytes
What it means
HandyControl's GPStream (a COM IStream wrapper used for GIF decoding) throws EFail with "Wrote an incorrect number of bytes" during CopyTo when the wrapped pstm.Write call returns a byte count different from the number of bytes Read returned. This is an internal invariant violation indicating the underlying IStream implementation misbehaved (short write or reported count mismatch).
Solutions
- Check the health of the underlying stream source (disk space, whether the COM stream was disposed/closed by another owner).
- Re-load the GIF from a fresh stream (e.g. new FileStream/MemoryStream) rather than reusing a suspect COM stream.
- If the stream comes from interop, verify the IStream implementation correctly returns the number of bytes written from Write.
- Wrap copy/decode calls in try-catch for COMException/IOException and fall back to an alternative decoder path.
Defensive patterns
Strategy: try-catch
Validate before calling
// Before decoding, confirm the stream is readable and has data:
if (stream == null || !stream.CanRead || stream.Length == 0)
throw new InvalidOperationException("GIF source stream is unreadable or empty"); Type guard
static bool IsUsableStream(System.IO.Stream s) =>
s != null && s.CanRead && (s.CanSeek ? s.Length > 0 : true); Try / catch
try
{
// decode GIF via GPStream-backed object
}
catch (System.Runtime.InteropServices.COMException ex)
when (ex.Message.Contains("Wrote an incorrect number of bytes"))
{
// re-acquire a fresh stream and retry once, else fall back to alternate loader
} Prevention
- Do not share one COM IStream across components; give each decoder its own stream.
- Keep the native stream alive until all copy/decode work completes.
- Check disk space and stream disposal order before GIF decode.
- Wrap interop decoding in a retry with a freshly opened stream.
When it happens
Trigger: CopyTo copies cb bytes in bufsize chunks; if Read(buffer, toRead) returns read > 0 but pstm.Write(buffer, read) returns any value != read, the exception is thrown on the very next loop iteration check.
Common situations: Decoding a GIF via a stream backed by a COM/interop IStream (e.g. from clipboard, OLE storage, or a native component) whose Write implementation is buggy or partially fails mid-copy; disk-full or stream closed underneath during copy.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
AI-assisted analysis of HandyOrg/HandyControl@2c0875ebd6 (2026-09-14).
Data as JSON: /api/errors/52d7e480527e6c84.
Report an issue: GitHub.
Appendix: source
Thrown at src/Shared/HandyControl_Shared/Data/Gif/GPStream.cs:92
]
public virtual long CopyTo(InteropValues.IStream pstm, long cb, long[] pcbRead)
{
const int bufsize = 4096;
var buffer = Marshal.AllocHGlobal(bufsize);
if (buffer == IntPtr.Zero) throw new OutOfMemoryException();
long written = 0;
try
{
while (written < cb)
{
var toRead = bufsize;
if (written + toRead > cb) toRead = (int) (cb - written);
var read = Read(buffer, toRead);
if (read == 0) break;
if (pstm.Write(buffer, read) != read)
{
throw EFail("Wrote an incorrect number of bytes");
}
written += read;
}
}
finally
{
Marshal.FreeHGlobal(buffer);
}
if (pcbRead != null && pcbRead.Length > 0)
{
pcbRead[0] = written;
}
return written;
}
public virtual Stream GetDataStream()
{View on GitHub (pinned to 2c0875ebd6)