Menu

#1021 Windows 11 build 26200.8116 entirely broke crtdll.dll

v1.0 (example)
open
nobody
None
5
2 hours ago
2026-03-29
No

I received reports from my users that couldn't load my binary on this windows 11 version. The binary was failing to find the symbol __mb_cur_max_dll from crtdll.dll, after investigating a bit, it seems like microsoft decided to break that dll as it is now straight up a copy of msvcrt40.dll, breaking the imports of symbols that in crtdll.dll had the _dll suffix.
This is obviously on microsoft's side, since they broke components that had been stable for 30 years, don't really know if this project can do anything for this (since it's a broken base assumption that held for all this time). But is there even a way (especially nowadays) to report this kind of issues to the proper channels

Discussion

  • Thierry DECHAIZE

    I confirm this. Suddenly, on W11 25H2 family edition 64 bit, my test with LCC compiler break.
    I execute, before use of this compiler, just "lcc -v" and error message Windows appear :
    "... GetMainArgs unreachable ..."
    I search with tool "lddw" (porting of ldd on Win32) directly to know what DLL is breaking, and listing stop after load of "crtdll.dll" (stored in usual directory C:\Windows\SysWOW64 in which all 32 bit DLL are stored on W11 64 bit).
    I compare size of this DLL on my "old" configuration fix PC (resdtrict to Win11 beginning version), and size are very different. To try, I transfer this most size DLL in C:\Windows\SysWOW64 (after manipulations with my "double boot" W11/Linux on my laptop), and ... YES, I resolve this problem.
    "lcc -v" work again -> It's very important misuse if M$ change this DLL without estimate impact on standard call to obtain args on command line ... or another lacking symbol ...
    Yes, not all executable on Win32 use CRTDLL.DLL, and many use at place "MSVCRT.DLL" (or assimiled), but why decide to change it ? To disturb some users ?
    Regards.

     
  • Pali

    Pali - 2 hours ago

    msvcrt40.dll and crtdll.dll are completely different libraries with different symbols and even few symbols which are present in both libraries have different ABI. So replacing crtdll.dll by msvcrt40.dll would not work. mingw-w64 header files uses macros which expands to UCRT ABI functions during compilation and then mingw-w64 crt contains implementation of those UCRT functions via chosen msvcr*/crtdll library and its exported symbols which are used during final linking.

    You can compare mingw-w64 def files which contains definitions of library symbols:
    https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib32/crtdll.def.in
    https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib32/msvcrt40.def.in

    crtdll.dll in all Windows versions up to Windows 10 do not have those mb_cur_max_dll symbols without the _dll suffix. All are always with _dll suffix. If MS decided to drop them they basically broke all existing crtdll.dll applications. mingw-w64 cannot do anything with it. You can just choose to compile and links against msvcrt.dll library instead of crtdll.dll

    I would suggest to report this issue to Microsoft, so they would be aware of this breakage and could fix it in next Windows update.

     

Log in to post a comment.

MongoDB Logo MongoDB