Which OS version the system started pushing this WM_SETTINGCHANGE window message

No publicly documented Windows version identifies when dock detachment first began producing WM_SETTINGCHANGE; determine the regression boundary by logging its payload on the last unaffected and first affected builds.

WM_SETTINGCHANGE itself is not new in Windows 11: its generic contract lists Windows 2000 Professional as the minimum supported client. That date applies to the message—not necessarily to the specific SystemDockMode or ConvertibleSlateMode payloads. Microsoft documents both strings as possible lParam values when the corresponding system indicator changes, but does not specify which Windows build introduced either notification.^1^

Consequently, builds 26200.7171 and 26300.9457 demonstrate affected configurations, but do not establish that the behavior started in Windows 11 25H2 or 26H2.

Identify the actual notification

Temporarily instrument the application’s WindowProc and record:

• Timestamp, message ID, and wParam
• A copied lParam string
• Window styles and placement
• Current monitor and monitor bounds
• Whether the app was full-screen before and after detachment

For example:

case WM_SETTINGCHANGE:
{
    const wchar_t* area =
        lParam ? reinterpret_cast<const wchar_t*>(lParam) : L"(null)";

    LogSettingChange(GetTickCount64(), wParam, area);
    LogWindowState(hwnd); // styles, placement, monitor bounds

    if (wcscmp(area, L"SystemDockMode") == 0 ||
        wcscmp(area, L"ConvertibleSlateMode") == 0) {
        OnPostureOrDockSettingChanged(hwnd, area);
        return 0; // Only for payloads intentionally handled here
    }
    break; // Preserve the app's existing/default handling
}

Do not treat every WM_SETTINGCHANGE as an undock event. Its lParam normally identifies only the general settings area, and it can be null.^1^

Also log WM_DEVICECHANGE. Windows documents hardware changes such as docking and undocking through that message,^2^ with DBT_CONFIGCHANGED specifically indicating a configuration change caused by docking or undocking.^3^

Establish the first affected build

Test the same physical device with unchanged BIOS, dock firmware, and device drivers:

1. Capture the behavior on the newest known unaffected build.
2. Install successive cumulative updates or builds.
3. Repeat the same detach sequence after each change.
4. Compare the first affected trace with the last unaffected trace.
5. Record the complete build, such as 26200.7171, because the digits after the build family identify the installed update revision.^4^

This device control matters because Windows tablet behavior depends on posture information reported through SMBIOS, DeviceForm, and ConvertibleSlateMode. Windows 11 22H2 and later can also use ConvertibilityEnabled, if present, with precedence over the enclosure and device-form checks.^5^ A Fujitsu BIOS, ACPI, GPIO, or dock-driver change can therefore alter the notification without a universal Windows behavior change.

Prevent full-screen loss

Receiving WM_SETTINGCHANGE does not itself require an application to leave full-screen. Locate the application code or framework callback that responds to the message or subsequent display/placement changes.

For SystemDockMode or ConvertibleSlateMode:

1. Recalculate the target monitor and work area.
2. Reapply the app’s saved full-screen styles and placement after the dock/display transition settles.
3. Ignore unrelated WM_SETTINGCHANGE payloads or pass them through normal processing.

The exact style and placement calls depend on whether the application uses raw Win32, WPF, WinUI, Qt, or another framework.

Escalation for a definitive boundary

If controlled testing cannot isolate the first build, open a Microsoft Support case and a Fujitsu enterprise-support case. Include:

• Last unaffected and first affected full OS builds and KB numbers
• Device, dock, BIOS, firmware, and driver versions
• A minimal reproduction
• Traces showing WM_SETTINGCHANGE, its copied lParam, WM_DEVICECHANGE, styles, placement, and monitor bounds
• Whether SystemDockMode or ConvertibleSlateMode changed

Microsoft can investigate Windows build history; Fujitsu can verify whether its firmware or drivers changed the dock/posture state reported to Windows.

References

1. WM_SETTINGCHANGE message
2. Device Messages
3. DBT_CONFIGCHANGED event
4. Differences in Description of Windows Version - Microsoft Q&A
5. Recommended settings for better tablet experiences