| Previous | Next |
| ERROR_STACK_OVERFLOW | ERROR_CAN_NOT_COMPLETE |
ERROR_INVALID_MESSAGE
the window cannot act on the sent message.
ERROR_INVALID_MESSAGE means that a window or GUI subsystem component rejected a message that is not valid in its current context. In this case, the decisive context is SendMessage, PostMessage, dialog, menu, clipboard, or window-management operations, together with message number, symbolic name, HWND, class name, process, and thread.
Where the result appears
- SendMessage, PostMessage, dialog, menu, clipboard, or window-management operations.
- cross-thread or cross-process GUI automation.
- messages sent before window initialization or after teardown.
- custom controls receiving a message with incompatible parameters or state.
Typical causes
- the target window class does not support the message.
- the message is valid only during a specific modal, menu, clipboard, or lifecycle state.
- wParam or lParam does not match the documented contract.
- the HWND is stale, belongs to another desktop/session, or changed ownership.
Evidence to collect
- message number, symbolic name, HWND, class name, process, and thread.
- wParam/lParam values and ownership of any pointed-to memory.
- window creation/destruction timeline and current UI state.
- whether the call crosses process, integrity, desktop, or session boundaries.
For this condition, begin the investigation with message number, symbolic name, HWND, class name, process, and thread. Correlate it with wParam/lParam values and ownership of any pointed-to memory and check whether the target window class does not support the message. Capture the original this result immediately after the failing call so later cleanup does not replace the thread-local error value.
Handling and recovery
Check the message contract and the target window lifecycle rather than converting the result into a generic UI failure. Prefer documented control APIs or accessibility/UI Automation interfaces for cross-process work. Never pass process-local pointers in a message whose receiver runs in another process unless the API explicitly marshals them.
Any retry policy for this Win32 error should be tied to evidence that the message is valid only during a specific modal, menu, clipboard, or lifecycle state has changed. Before another attempt, verify window creation/destruction timeline and current UI state. If the HWND is stale, belongs to another desktop/session, or changed ownership still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
The code does not imply that the window handle is always invalid. A real window may reject a message that is unsupported or illegal at that moment.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by cross-thread or cross-process GUI automation. A useful telemetry record also includes whether the call crosses process, integrity, desktop, or session boundaries. For a-related handling, decisions must use the numeric value and documented API contract rather than localized wording.
A focused test should reproduce the condition in which wParam or lParam does not match the documented contract, assert this result, and confirm that the program releases resources associated with messages sent before window initialization or after teardown. The recovery test should also verify that message number, symbolic name, HWND, class name, process, and thread is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.