What Causes ERROR_TLW_WITH_WSCHILD (0x0000057E)?
You'll see this error when calling CreateWindow or CreateWindowEx in C/C++ or .NET and you set both the WS_CHILD and WS_POPUP (or WS_OVERLAPPED) styles on the same window. The system cannot create a window that's both a child (attached to a parent) and a top-level window (has its own desktop anchor).
I've seen this most often in older MFC apps and WinForms projects where someone copies code from a dialog and forgets to strip out the conflicting styles. It also happens in automation scripts that try to reparent windows incorrectly.
Here's the exact error message from the Windows SDK header file winerror.h:
//
// MessageId: ERROR_TLW_WITH_WSCHILD
// MessageText: Cannot create a top-level child window.
//
#define ERROR_TLW_WITH_WSCHILD 1406L
The decimal value is 1406, hex is 0x57E. You'll see it as an HRESULT in logs or a return code from GetLastError().
Fix #1: Check Your Window Style Combination (Most Common)
The number one cause is combining WS_CHILD with WS_POPUP or WS_OVERLAPPED. These are mutually exclusive. Windows interprets WS_POPUP and WS_OVERLAPPED as top-level window styles, while WS_CHILD is for child windows.
Here's what to look for in your code:
// WRONG — this will fail with ERROR_TLW_WITH_WSCHILD
HWND hWnd = CreateWindow(
L"STATIC",
L"My Window",
WS_CHILD | WS_POPUP | WS_VISIBLE, // conflict here
0, 0, 200, 100,
hParent,
NULL,
hInstance,
NULL
);
// RIGHT — remove WS_POPUP
HWND hWnd = CreateWindow(
L"STATIC",
L"My Window",
WS_CHILD | WS_VISIBLE, // only child styles
0, 0, 200, 100,
hParent,
NULL,
hInstance,
NULL
);
If you need a top-level window (one that can live outside the parent's client area), then drop WS_CHILD and use WS_OVERLAPPEDWINDOW or WS_POPUP instead. But remember, a top-level window has no parent — if you pass a parent handle, it becomes owned, not a child.
What to expect after the fix: Recompile and run. The window should appear without the error. If you're using a framework like MFC or WinForms, check the control's style in the resource editor or properties pane.
Fix #2: If You're Using .NET WinForms or WPF
.NET wrappers can also trigger this error, especially if you're doing custom window creation or using interop with CreateParams.
In WinForms, if you override CreateParams and set Style to include both WS_CHILD and a top-level style, you'll get 0x57E. Here's a typical offender:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.Style |= 0x80000000; // WS_POPUP — but form already has WS_CHILD from being a child control
return cp;
}
}
Instead, only set WS_CHILD if the control is meant to be a child. If you need a popup, make the form a top-level form by setting TopLevel = true and FormBorderStyle = FormBorderStyle.None. Don't include WS_CHILD in the style.
For WPF, this is less common because WPF handles its own windowing. But if you're hosting Win32 windows inside a WPF HwndHost, you might run into it. The fix is the same: ensure the hosted window uses WS_CHILD only, without WS_POPUP or WS_OVERLAPPED.
What to expect: After removing the conflicting style, the control or form will either become a proper child or a proper top-level window. The error disappears at creation time.
Fix #3: Reparenting or Window Hierarchy Mistakes
Sometimes the error shows up when you try to reparent a window using SetParent and the window already has conflicting styles. For example, you might have a popup window that you try to make a child of another window at runtime.
I've debugged this in remote desktop apps and custom tab controls. The window starts as top-level, then someone calls SetParent() without updating the style flags. The window still has WS_POPUP, but now it also gets treated as a child because it has a parent.
The correct approach: before calling SetParent, remove the top-level styles and add WS_CHILD. Here's how:
// Before reparenting, change the window style
LONG style = GetWindowLong(hWnd, GWL_STYLE);
style &= ~(WS_POPUP | WS_OVERLAPPED); // remove top-level styles
style |= WS_CHILD; // add child style
SetWindowLong(hWnd, GWL_STYLE, style);
// Now reparent
SetParent(hWnd, hNewParent);
// Force the window to update its visual
SetWindowPos(hWnd, NULL, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_FRAMECHANGED);
If you don't call SetWindowPos with SWP_FRAMECHANGED, the window might not redraw correctly. That's a separate issue but it'll save you a headache.
What to expect: The SetParent call succeeds, no 0x57E error. You'll see the window move under the new parent. If it doesn't repaint, trigger InvalidateRect on it.
Quick Reference Summary Table
| Cause | Symptom | Fix | Code Change |
|---|---|---|---|
| Combining WS_CHILD with WS_POPUP/WS_OVERLAPPED | CreateWindow fails, GetLastError returns 1406 | Remove the top-level style, keep only WS_CHILD | dwStyle = WS_CHILD | WS_VISIBLE; |
| .NET WinForms CreateParams override | Form/control fails to create | Don't add WS_POPUP to a child control's style | Remove cp.Style |= 0x80000000; |
| Reparenting a top-level window | SetParent fails or window disappears | Change style to WS_CHILD before reparenting | SetWindowLong + SetWindowPos |
That covers it. The error is almost always a style mismatch. Double-check your window styles, and you'll be past it in minutes. If you're still stuck after these steps, post your CreateWindow call (or the relevant code) and I'll spot the conflict for you.