Windows 11 26H1 build 28000.3501 (KB5132059) has resulted in some .exe files failing to execute.

Question

Windows 11 26H1 build 28000.3501 (KB5132059) has resulted in some .exe files failing to execute.

C H 0

An executable compiled with #pragma comment(linker, "/align:16") no longer runs after upgrading to Windows 11 26H1 build 28000.3501 (KB5132059).

Source code of minimal reproducer:

#pragma comment(linker, "/merge:.rdata=.text")
#pragma comment(linker, "/align:16")

#include <windows.h>

static const char kMsg[] = "hello world\r\n";

int main() {
    DWORD written = 0;
    WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), kMsg, sizeof(kMsg) - 1, &written, NULL);
    return 0;
}

or the base64 of the exe to reproduce:

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAwAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAAl1gHHYbdvlGG3b5Rht2+U9z5ulWK3b5Rht26UY7dvlMU6apVgt2+UxTpt
lWC3b5RSaWNoYbdvlAAAAAAAAAAAUEUAAGSGAwDSWPVqAAAAAAAAAADwACIACwIOM3ABAACgAAAA
AAAAAGADAABAAgAAAAAAQAEAAAAQAAAAEAAAAAYAAAAAAAAABgAAAAAAAABQBAAAQAIAAAAAAAAD
AGCBAAAQAAAAAAAAEAAAAAAAAAAAEAAAAAAAABAAAAAAAAAAAAAAEAAAAAAAAAAAAAAA2AMAACgA
AAAAAAAAAAAAALADAAAMAAAAAAAAAAAAAAAAAAAAAAAAAFACAAAcAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMADAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
LnRleHQAAABsAQAAQAIAAHABAABAAgAAAAAAAAAAAAAAAAAAIAAAYC5wZGF0YQAADAAAALADAAAQ
AAAAsAMAAAAAAAAAAAAAAAAAAEAAAEAuaWRhdGEAAIIAAADAAwAAkAAAAMADAAAAAAAAAAAAAAAA
AABAAABAaGVsbG8gd29ybGQNCgAAAAAAAADSWPVqAAAAAA0AAADcAAAAhAIAAIQCAAAYAAAAAIAA
gAAAAAAAAAAAAAAAAAAAAAAAAAAAQAIAACwAAAAucmRhdGEAAGwCAAAYAAAALnJkYXRhJHZvbHRt
ZAAAAIQCAADcAAAALnJkYXRhJHp6emRiZwAAAGADAABEAAAALnRleHQkbW4AAAAApAMAAAgAAAAu
eGRhdGEAALADAAAMAAAALnBkYXRhAADAAwAAGAAAAC5pZGF0YSQ1AAAAANgDAAAUAAAALmlkYXRh
JDIAAAAA7AMAABQAAAAuaWRhdGEkMwAAAAAABAAAGAAAAC5pZGF0YSQ0AAAAABgEAAAqAAAALmlk
YXRhJDYAAAAASIPsOLn1////x0QkQAAAAAD/FVEAAABMjUwkQEjHRCQgAAAAAEiLyEiNFbH+//9B
uA0AAAD/FSUAAAAzwEiDxDjDzMwBBAEABGIAAAAAAABgAwAAogMAAKQDAAAAAAAAKAQAAAAAAAAY
BAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAANAQAAMADAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgE
AAAAAAAAGAQAAAAAAAAAAAAAAAAAAAYDR2V0U3RkSGFuZGxlAABjBldyaXRlRmlsZQBLRVJORUwz
Mi5kbGwAAAAAAAAAAAAAAAAAAAAA

remove "align:16" will correct the exe, but it’s a product, so replacing the .exe isn’t something we can do casually.

which update changes the launch of low-alignment executables?

0 comments

1 answer

Your answer

Answer 1

Hi, @C H

Nothing in the public record documents this change. The KB5132059 release notes list only security fixes, the USB audio fix, printer fix, NTLM signing changes and a DST update, and the 26H1 release health page shows no known issue about executables failing to launch, so there is no confirmed update to point to yet.

Here are some suggestions you can try:

First, pin down the exact failure. Launch the exe from a Command Prompt and note the message, then open Event Viewer and check Windows Logs > Application and System, plus Applications and Services Logs > Microsoft > Windows > CodeIntegrity. If the code is 0xC000007B (invalid image format), the loader itself is rejecting the file. If you see a CodeIntegrity or Smart App Control entry instead, the file is being blocked by policy rather than failing to map. 26H1 ships only preinstalled on new hardware, and Smart App Control is on by default on those machines, so an unusual PE layout like 16-byte section alignment is a plausible trigger. Check Windows Security > App & browser control > Smart App Control settings, and Protection history, to see if it logged a block.

Second, confirm the update is actually the cause. Go to Settings > Windows Update > Update history > Uninstall updates, remove KB5132059, reboot and test. If the exe runs again, pause updates for a few weeks while you sort out a fix. That is a stopgap, not a solution, since the security fixes go with it.

Third, since this is a shipping product, open a case through Microsoft Support for business or Developer Support rather than consumer channels, and attach the reproducer, the dumpbin /headers output and the Event Viewer entries. That is the route that reaches the Windows servicing team and can result in a Known Issue Rollback if they confirm a regression. The /ALIGN docs do say the default is 4096 and that changing it is only expected for things like drivers, so expect them to ask why 16 is needed.

If you can share the exact error code or event, I can help narrow it down further.