startup error on Windows11 24H2

[Niteip]

My program uses the mimalloc dynamic library, and when it starts on Windows 11 24H2, a popup error occurs stating, "The application was unable to start correctly (0xc0000142). Click OK to close the application." I have tested it and found that it works normally on Windows 11 23H2. Currently, I have switched the dynamic library to a static library, and users on Windows 11 24H2 are not encountering any startup errors.

[Niteip]

Sorry for forgetting to mention that I am using version 2.1.7 of mimalloc

[daanx]

Yikes -- that's a bit scary. I recently updated the redirection dll; can you perhaps try with the latest dev-slice branch if you still see the same issue? (I am currently traveling and have no easy means to set up a test environment now).

Also, if it still fails, can you try with the environment variable MIMALLOC_VERBOSE=3 and see if there is any error output?

[vitalyt79]

I have the same problem with the latest mimalloc-redirect.dll version

Unhandled exception at 0x00007FF891B55CC9 (ntdll.dll) in 1.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

Call stack:

ntdll.dll!RtlUnicodeStringToAnsiString() Unknown
mimalloc-redirect.dll!00007ff86ca94007() Unknown
mimalloc-redirect.dll!00007ff86ca95289() Unknown
mimalloc-redirect.dll!00007ff86ca92f33() Unknown
ntdll.dll!LdrEnumerateLoadedModules() Unknown
mimalloc-redirect.dll!00007ff86ca9302a() Unknown
mimalloc-redirect.dll!00007ff86ca9597e() Unknown
mimalloc-redirect.dll!00007ff86ca92a40() Unknown
mimalloc-redirect.dll!00007ff86ca9237b() Unknown
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode() Unknown
ntdll.dll!LdrpInitializeGraphRecurse() Unknown
ntdll.dll!LdrpInitializeGraphRecurse() Unknown
ntdll.dll!LdrpInitializeGraphRecurse() Unknown
ntdll.dll!LdrpInitializeProcess() Unknown
ntdll.dll!_LdrpInitialize() Unknown
ntdll.dll!LdrpInitializeInternal() Unknown
ntdll.dll!LdrInitializeThunk() Unknown

[daanx]

Ah great -- thanks, I'm looking into it. It is a bit strange to see an access violation inside ntdll though...
(I looked but couldn't find an obvious mistake on my side so I need to somehow set up a test environment with Win11 24H2, this may take a bit as I am traveling)

[daanx]

I updated mimalloc-redirect in the latest dev and dev-slice. This might fix the issue (but probably not). If you can try it that would be great.

[vitalyt79]

It didn't work for me, the same error.

[daanx]

Ok -- I need to get my hands on a 24H2 windows version then -- that would be earliest later next week though :-(

[vitalyt79]

ok, thanks a lot. BTW I'm using version 2.0.3.

[Niteip]

I updated mimalloc-redirect in the latest dev and dev-slice. This might fix the issue (but probably not). If you can try it that would be great.

Thank you for your work. I will test it tomorrow.

[Niteip]

I updated mimalloc-redirect in the latest dev and dev-slice. This might fix the issue (but probably not). If you can try it that would be great.

I conducted two tests,
Test 1: Download dev, compile and obtain mimalloc-override.dll and mimalloc-redirect.dll, run, and get an error 0xc0000142
Test 2: Download dev-slice, perform the above steps, run it, and also report an error 0xc0000142
Then I tried compiling with MIMALLOC_VERBOSE=3, but I realized that when the error 0xc0000142 occurred, my program did not output any log files that it should have. What I mean is: Windows has a loader that does a bunch of checks on the program when it tries to run it, and only if it passes those checks does it create a process and then execute WinMain(). I guess that the error 0xc0000142 is not passed during the check stage, so there is no output log file, which means that MIMALLOC_VERBOSE=3 will not bring information.

[daanx]

I got my hands on Windows 24H2, version 10.0.26100.2314 (use winver to see this).

I could not reproduce the issue though.

I see patch 2314 came out on Nov 12 -- maybe this fixed the issue? Can you try this?

[Niteip]

I got my hands on Windows 24H2, version 10.0.26100.2314 (use winver to see this).

I could not reproduce the issue though.

I see patch 2314 came out on Nov 12 -- maybe this fixed the issue? Can you try this?

On my machine, winver shows 26100.1742

[Niteip]

I got my hands on Windows 24H2, version 10.0.26100.2314 (use winver to see this).

I could not reproduce the issue though.

I see patch 2314 came out on Nov 12 -- maybe this fixed the issue? Can you try this?

I tried the 2314 patch (downloaded from https://www.windowslatest.com/2024/11/12/windows-11-kb5046617-24h2-out-with-fixes-direct-download-msu/), after installing it and restarting my computer, winver showed 26100.2314.

Then, when I ran my program, the error 0xc0000142 still persisted.

[Niteip]

I got my hands on Windows 24H2, version 10.0.26100.2314 (use winver to see this).

I could not reproduce the issue though.

I see patch 2314 came out on Nov 12 -- maybe this fixed the issue? Can you try this?

I tried to create a new project with VS, a console application, and then introduced mimalloc (using the same dynamic libraries, mimalloc-override.dll and mimalloc-redirect.dll, following the same steps). When I ran it on Windows 11 24H2, everything worked fine, and the console printed "Hello World!".

Oh my goodness, now I'm completely at a loss. I don't know how to solve the issue with my program.

[vitalyt79]

For me the problem was solved after I added the inclusion of the <mimalloc-new-delete.h> to the file that contains the main function.

[pzompolas]

I had the same issue too (started happening after I upgraded to 24H2).

Mine is a simple Qt application and I was (probably incorrectly), doing the #include "mimalloc-override.h" after including the Qt headers. Moving mimalloc-overide near the top of the include chain seems to have fixed the issue, although I'm now getting compile warnings about Qt (C:\Qt\6.7.1\msvc2019_64\include\QtCore\qhash.h(123,15): warning C4003: not enough arguments for function-like macro invocation 'free').

Still... better than the immediate startup crash :-)

Hope this helps someone

[Johen8]

We are having the same problem here too, updated Windows to 24H2 (26100.2314) over the weekend, now (Monday), got this access violation, we are using mimalloc version 1.8.7:

 	ntdll.dll!_RtlUnicodeToCustomCPN@24()	Unknown
 	ntdll.dll!_RtlUnicodeToMultiByteN@20()	Unknown
 	ntdll.dll!RtlUnicodeStringToAnsiString()	Unknown
 	mimalloc-redirect32.dll!74412ec4()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for mimalloc-redirect32.dll]	
 	mimalloc-redirect32.dll!744139ad()	Unknown
 	mimalloc-redirect32.dll!744126da()	Unknown
 	ntdll.dll!LdrEnumerateLoadedModules()	Unknown
 	mimalloc-redirect32.dll!74412746()	Unknown
 	mimalloc-redirect32.dll!74413ee4()	Unknown
 	mimalloc-redirect32.dll!744122ff()	Unknown
 	ntdll.dll!_LdrxCallInitRoutine@16()	Unknown
 	ntdll.dll!LdrpCallInitRoutine()	Unknown
 	ntdll.dll!_LdrpInitializeNode@4()	Unknown
 	ntdll.dll!LdrpInitializeGraphRecurse()	Unknown
 	ntdll.dll!LdrpInitializeGraphRecurse()	Unknown
 	ntdll.dll!LdrpInitializeGraphRecurse()	Unknown
 	ntdll.dll!_LdrpInitializeProcess@8()	Unknown
 	ntdll.dll!__LdrpInitialize@8()	Unknown
 	ntdll.dll!_LdrpInitializeInternal@8()	Unknown
>	ntdll.dll!LdrInitializeThunk()	Unknown

Not sure if it makes sense, but only seems to happen with debug version, not release version

[solort]

We're experiencing the same issue after updating to Windows 24H2 (26100.1742) this week. We're encountering an access violation and are using mimalloc version 2.0.6.

[Johen8]

I had to revert my Windows to 23H2, @daanx could you give us any feedback on this? Even if it's "I'm not gonna fix it", because then we can at least look for other options.

[daanx]

Hmm, this is not great. Unfortunately, I cannot repro the problem (yet). I wonder if it has to do with a locale setting, or DLL's with paths that contain fun unicode characters. If anyone has an exe that reproduces this, that would be great.

Another thing I could do is remove the calls to RtlUnicodeToAnsiString -- maybe that would fix it. I checked the code though and all parameters are good -- really strange it fails. TBC.

[vitalyt79]

This problem occurs when the main project is built first with a <mimalloc-new-delete.h> header included, and then another executable is built using the same generated object files, but the file containing the main function in the second executable doesn't include the <mimalloc-new-delete.h> header. In my case, the project's executable was built first, and then unit tests were built using the generated object files, but the file containing the main function in the unit tests didn't include the <mimalloc-new-delete.h> header.

[daanx]

So, I created a version of the redirect that avoids calling RtlUnicodeStringToAnsiString -- maybe it will avoid the crash; As I can't repro myself it is a bit of an experiment, for now, you can download a binary (dll+lib) at:

https://www.dropbox.com/scl/fi/b912kfrtumqqp4rir4mmn/mimalloc-redirect-v1.2.zip?rlkey=yzqep48iuqnklypg5utcb94go&e=1&st=42poy9xx&dl=1

It works with any mimalloc version, just make sure the files are in the same folder as the executable (and overwrite the old dll that is failing). Then run with MIMALLOC_VERBOSE=3 and check if the redirect module is v1.2 and what it thinks the windows version is -- well, if it doesn't crash.

[DuShijun]

So, I created a version of the redirect that avoids calling RtlUnicodeStringToAnsiString -- maybe it will avoid the crash; As I can't repro myself it is a bit of an experiment, for now, you can download a binary (dll+lib) at:

https://www.dropbox.com/scl/fi/b912kfrtumqqp4rir4mmn/mimalloc-redirect-v1.2.zip?rlkey=yzqep48iuqnklypg5utcb94go&e=1&st=42poy9xx&dl=1

It works with any mimalloc version, just make sure the files are in the same folder as the executable (and overwrite the old dll that is failing). Then run with MIMALLOC_VERBOSE=3 and check if the redirect module is v1.2 and what it thinks the windows version is -- well, if it doesn't crash.

I tried replacing this version of mimalloc-redirect, but unfortunately, the crash issue still occurs.
It seems that the issue is not limited to the RtlUnicodeStringToAnsiString interface alone.

[daanx]

:-( Can you capture a stack trace ? Otherwise, if any of you have an exe that can be shared, maybe that helps me to get a repro on my local machine. (best is of course source code for the exe so I can build it myself)

[DuShijun]

:-( Can you capture a stack trace ? Otherwise, if any of you have an exe that can be shared, maybe that helps me to get a repro on my local machine. (best is of course source code for the exe so I can build it myself)

Hi, on my machine, this can be reproduced using the mimalloc-override-test.
The program crashes in the function at offset 0x3860 (screenshot 1). The result is an array obtained via LdrFindEntryForAddress, and the second parameter passed to RtlUnicodeStringToAnsiString is an element of this array, accessed by its index. I suspect that this might be an out-of-bounds access? (Could this be why the issue persists even after replacing RtlUnicodeStringToAnsiString in mimalloc-redirect v1.2?)
The previous stack trace is from the function at offset 0x4AB0 (see screenshot 2). It seems that this issue is intermittent and related to the DLL load order? When the load order is correct, the issue does not occur.

[daanx]

on my machine, this can be reproduced using the mimalloc-override-test.

What is the locale setting? Also, if you think it is the load order, maybe you can use bin\minject -l <exe> to see what the exact load order is . If you do this for a crashing mimalloc-override-test.exe , you can then try to use minject to change the load order and see that fixes things. It might be something else still, like some sort of stack overflow? It is strange it doesn't always happen -- hope I can find a repro :-(

[DuShijun]

on my machine, this can be reproduced using the mimalloc-override-test.

I used minject to check the debug program's load order, and everything seemed fine (see Figure 1).
However, when running the program, the load order is shown in Figure 2, where it is clear that ucrtbase was loaded before mimalloc.
The function I previously suspected at offset 0x4AB0 did indeed hit the 'incorrect load order' branch, which led to the exception later on (see Figures 3 and 4).
And I found this computer has an encryption system installed, which seems to hook DLL loading and perform some operations of its own, causing the load order to be disrupted. If you'd like to reproduce this issue, perhaps you could write a small program to simulate this scenario?I‘m wondering if others who reproduce the issue are encountering the same situation?
BTW, when this scenario occurs, Windows versions prior to 24H2 do not trigger the crash, and I’m not sure why that is yet.

[daanx]

Thanks for all the traces -- I'll look further into trying to repro on my machines. I need to figure out how to trigger this, and what is different:

• it seems even mimalloc-override-test can trigger it
• some people report including new-delete (or not) can trigger it
• some people only have this in debug or release mode

If you experience a crash, please also report:

• did you use C++ or C compilation?
• what is the Locale setting?
• are there non-ascii characters in any DLL path of imported modules?
• what is the exact windows version? (use winver to see this)
• anything??

[Johen8]

• did you use C++ or C compilation?
  C++
• what is the Locale setting?
  en-US or pt-BR
• are there non-ascii characters in any DLL path of imported modules?
  No
• what is the exact windows version? (use winver to see this)
  26100.2314
• anything??
  I'll see if I can send you binaries that reproduce the problem, is there any way I can send you them privately?

[daanx]

I gave it another try -- I cannot repro still; but maybe the following version of mimalloc-redirect.dll may fix things? (v1.3)? If anyone can try, let me know how it goes:

https://www.dropbox.com/scl/fi/bxct5rlldrou3ibe6kwbv/mimalloc-redirect-v1.3.zip?rlkey=q9w9xyuxomltrgberc4oplofz&st=1m3cvoy4&dl=1

[DuShijun]

Thanks for all the traces -- I'll look further into trying to repro on my machines. I need to figure out how to trigger this, and what is different:

• did you use C++ or C compilation?
  C++
• what is the Locale setting?
  zh-CN
• are there non-ascii characters in any DLL path of imported modules?
  No
• what is the exact windows version? (use winver to see this)
  26100.1301

[aMoonkin]

I gave it another try -- I cannot repro still; but maybe the following version of mimalloc-redirect.dll may fix things? (v1.3)? If anyone can try, let me know how it goes:

https://www.dropbox.com/scl/fi/bxct5rlldrou3ibe6kwbv/mimalloc-redirect-v1.3.zip?rlkey=q9w9xyuxomltrgberc4oplofz&st=1m3cvoy4&dl=1

Thanks @daanx , this works for me. Can you tell me from which version of mimalloc this dll was compiled? It could be the commit id, or the tag.

did you use C++ or C compilation?
C++
what is the Locale setting?
zh-CN
are there non-ascii characters in any DLL path of imported modules?
No
what is the exact windows version? (use winver to see this)
26100.2605

[DuShijun]

I gave it another try -- I cannot repro still; but maybe the following version of mimalloc-redirect.dll may fix things? (v1.3)? If anyone can try, let me know how it goes:

Also works for me! Really appreciate it, thanks so much!

[daanx]

Also works for me! Really appreciate it, thanks so much!

Great to hear this :-) I pushed updated redirection modules to the latest dev branch (later dev-slice will get it too). Please let me know if these work for you.