| Previous | Next |
| ERROR_NO_MORE_USER_HANDLES | ERROR_SOURCE_ELEMENT_EMPTY |
ERROR_MESSAGE_SYNC_ONLY
The selected window message cannot be delivered asynchronously.
ERROR_MESSAGE_SYNC_ONLY has decimal value 1159 (0x487). It indicates that the message involved is valid only with a synchronous operation, while the caller attempted to queue, post, or otherwise deliver it asynchronously. The numeric result does not identify the message; the message ID and sending API are essential context.
Synchronous and asynchronous delivery are not interchangeable
SendMessage invokes or coordinates with the target window procedure before returning, so data referenced by the message remains available for the duration of the call. PostMessage places a message in a queue and returns immediately. Any pointer to a stack object, temporary buffer, or caller-owned structure may be invalid by the time the receiver removes a posted message.
Typical programming mistakes
- replacing
SendMessagewithPostMessageto avoid a hang without reviewing the message contract - posting a system-defined message whose parameters require synchronous marshalling
- passing pointers through a queued custom message without transferring ownership
- using a broadcast or notify API that has different restrictions from direct sending
- wrapping a synchronous control message in a generic asynchronous dispatcher
Data to record
- message number in hexadecimal and its symbolic name when known
- delivery function, destination
HWNDor thread ID, and caller thread ID wParam/lParaminterpretation without logging sensitive pointed-to content- whether sender and receiver belong to different processes or integrity levels
- the lifetime and ownership rules for any structure referenced by the parameters
Preserve 1159 immediately after the failed call. Logging another window operation first can replace the thread's last-error value and obscure the delivery restriction.
Corrective design
If the documented message requires synchronous delivery, use the required send API and control blocking with architecture rather than changing the transport blindly. Options include moving the operation off the UI thread, using SendMessageTimeout where appropriate, or designing an application-defined request/response channel with copied data and explicit cancellation.
For custom queued messages, allocate data with a lifetime that extends until the receiver consumes it, define who frees it, and handle receiver shutdown. Better still, store payloads in a thread-safe queue and use the message only as a notification token.
Operational interpretation
This is normally a deterministic contract error, not a transient queue-capacity problem. Repeating the same post will continue to fail. An administrator cannot repair it by restarting Windows unless a third-party extension has injected the invalid call; the component choosing the wrong message API must be corrected.
Related results
ERROR_INVALID_MESSAGE indicates that a window cannot act on a sent message. ERROR_NOT_ENOUGH_QUOTA can be returned when a message queue limit is exceeded. ERROR_ACCESS_DENIED may reflect User Interface Privilege Isolation. Error 1159 specifically says the delivery mode is asynchronous when the message permits only synchronous use.
Example
A developer changes a control query from SendMessage to PostMessage so the caller will not wait. The query's lParam points to a stack structure that the control must fill before return. Windows rejects the asynchronous use with 1159. Restoring synchronous semantics—or replacing the query with an owned asynchronous request object—fixes both the error and the latent lifetime bug.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: PostMessageW function
- Microsoft: SendMessageW function
Looking for a different code? Search another status or error code.