| Previous | Next |
| STATUS_SINGLE_STEP | STATUS_NO_MORE_FILES |
STATUS_BUFFER_OVERFLOW
STATUS_BUFFER_OVERFLOW is often more useful than its name suggests. In NTSTATUS semantics it is a warning, not necessarily a total failure. A provider can return the portion of the result that fits in the caller's buffer and report this status to say that additional data did not fit.
Why callers must not discard the output automatically
Microsoft's driver guidance contrasts this status with STATUS_BUFFER_TOO_SMALL. With an overflow warning, the buffer can hold some meaningful output; with a too-small error, it cannot hold the required information at all. APIs commonly return a length or byte count that lets the caller determine whether the partial result is usable and how large the next buffer should be.
Correct handling pattern
- Check the documented status semantics for the specific API rather than treating every nonzero status as identical.
- Read the returned byte count or required length before reallocating.
- Preserve valid partial data only when the API documents it as safe to consume.
- Guard size calculations against integer overflow and place a reasonable upper limit on allocations from untrusted data.
For example, file-system and filter-manager APIs may return the fixed part of a structure while omitting variable-length names or data. A caller that tests status incorrectly can lose useful diagnostics or leak an uninitialized output buffer into later processing.
See Using NTSTATUS Values, FltGetVolumeProperties, and FSCTL_PIPE_PEEK status handling.
Looking for a different code? Search another status or error code.