Error 0xc0000142 occurred when installing or starting asan nightly.
From https://firefox-source-docs.mozilla.org/tools/sanitizer/asan_nightly.html

Windows 10 build number is 20277.1 however, the error occurred in previous insider builds.

I reinstalled the latest version but still reproduce.

Taegeon Lee, can you see if there are any crash reports in your profile directory? If they have been able to be uploaded, that should help track down what's going on here.

Additionally, if you could test with a fresh profile, that could be useful.

youtube: https://youtu.be/6abi7qpxtgg

I uninstalled and reinstalled Firefox asan with a fresh profile.
But error 0xc0000142 is still occurred.

The profile is stored separately from Firefox, and reinstalling the browser doesn't affect the profile. You can read instructions to find the profile directory in this support article.

Can you check if moving your profile temporarily (such as to your Desktop), helps the problem? Firefox should automatically create a new one to replace the one you moved away. The profile is where your bookmarks and browser history is stored, so I would recommend not deleting it entirely at first.

Additionally, the profile is where the crash data is stored. Can you look inside the crashes directory in your profile, and see if there are any crashes that have have been reported? The crash ID could be useful in figuring out what is going on here.

youtube: https://youtu.be/luhJdRhJ3VM

I temporarily delete profiles, but firefox asan 0xc0000142 is occurred.
Moreover, firefox asan installer occurred the error.

Were there any files in the crash directory in profile before you deleted it?

Honestly, I installed three firefox browsers (firefox nightly, firefox developer edition, firefox asan nightly)
However, I have only two profiles for firefox nightly and firefox asan nightly.

Firefox Nightly and Firefox ASan Nighly can share a profile, whereas Developer Edition cannot share a profile. In about:profiles (from your capture3.PNG screenshot), for the default-nightly directory, there is a button that in the English UI says "Open Directory". It should be the top of the two, labeled "Root directory" or something similar. Clicking that will open Explorer navigated to the profile directory. It is inside that directory that we are looking for the crashes directory. This is important because if there are crashes there it will greatly help figure out why Firefox is crashing. Without those crash files we cannot progress with this bug.

Hello,

I’ve attempted to reproduce the issue on Windows 10 Pro x64 build 18363.1082, however without success.

I downloaded the asan Nightly from https://firefox-source-docs.mozilla.org/tools/sanitizer/asan_nightly.html as mentioned in the report, more precisely from the Requirements section (https://firefox-source-docs.mozilla.org/tools/sanitizer/asan_nightly.html#requirements). I’ve mentioned this in detail in case I did not download the build from the correct source.

During installation I’ve encountered a .dll related error (see screenshot 1), however clicking on the “OK” button on the error panel, dismissed it and the installation process continued.

After installation, I launched Nightly with a new profile and the browser launched without encountering any errors. No errors were encountered wither on a second launch with an existing Nightly profile I have. I did observe some errors being output in the console window which launches before the browser (see screenshot 2).

Regarding the different OS build I used, for the moment I cannot update Windows due to an error in connecting to the update server. Will, however, attempt to reproduce the bug once more after I manage to update my OS.

It's not clear what is causing the error 0xc0000142, searching suggests that it indicates corrupt libraries and since that is happening when installing and running Firefox it might indicate that Windows libraries at fault.

The error in comment 14 however suggests that the asan build of the maintenance service relies on a runtime library that we aren't installing so I wonder if that library needs to be added to the installer and maybe that might solve the original issue? Over to the installer team for investigation.

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

The error from comment 14 is unrelated to the rest of the bug. The problem there is that we're building the maintenance service binary with ASAN instrumentation, but the maintenance service is installed to its own directory and we don't put a copy of the ASAN DLL in there, so it can't run. I'll file a separate bug for that, but it doesn't have anything to do with Firefox being able to run or not.

Error code 0xC0000142 is STATUS_DLL_INIT_FAILED, but it's difficult to tell which DLL didn't initialize or why not. I can reproduce the bug on 20231 as well, so I'm going to try and investigate.

The DLL that isn't initializing is the clang ASAN DLL itself; I verified that by writing an empty C program and compiling it using clang-cl /MD -fsanitize-address, and I get the same error from that program (interestingly, if I leave off /MD to get the statically linked version, everything works fine). So it would appear that some change landed in a recent Windows Insider build (20231 at the latest) has broken that DLL.

I would file a clang bug, but I don't have an account there; I'm hoping someone in the build system component does.

David I believe this is in LLT territory.

My guess is the insider build no longer has a function that ASan wants to hook. This sounds like a job for "Show Loader Snaps".

Molly, could you try the following with your empty test program and send me the log?

• Install WinDbg on the insider machine
• In the WinDbg installation directory is gflags.exe
• gflags -i TestProgramName.exe +sls
• Start the program under WinDbg; it will print very verbose loader messages
• gflags -i TestProgramName.exe -sls to undo the setting when you no longer want it

Another possibility is that the ASan DLL is crashing during DllMain. So if WinDbg catches any crashes while the program attempts to start, that would be good to know too.

I figured out what's going on: in the more recent insider builds, various system functions are no longer padded with sufficient int 3 for ASan to insert a hotpatch, so ASan falls back to using a trampoline, but its barebones instruction decoder now has to deal with a bunch of new instructions that it doesn't understand.

I can get around that by adding the necessary instructions to ASan's decoder, but then we hit an issue where a later part of ntdll!strrchr wants to jump to ntdll!strrchr+3 which has been clobbered now that we're placing a 5-byte trampoline at the function start.

I'll file this upstream later today.

Filed https://bugs.llvm.org/show_bug.cgi?id=48677

I think it is fixed as bug 1723593 is fixed.