2026594 - Intermittent Firefox crash while a third-party DLL hooks Firefox; crash stack ends in ntdll!wcslen / LoadLibraryExW

Status: RESOLVED INVALID

(External Software Affecting Firefox :: Other, defect)

Description

[yaziciogludefne]

Attachment: crash_report.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

What did you do? (steps to reproduce)
I use a custom DLL that hooks Firefox.
The DLL is also visible in about:third-party.

The issue is intermittent and I do not have fully reliable repro steps yet. In practice, it happens while Firefox is running normally with the DLL loaded. Sometimes Firefox runs without any problem, sometimes the whole browser crashes, and sometimes only one or two tabs crash.

What makes this difficult to understand is that the same hooking DLL seems to work without crashes in other applications.

User agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0

Actual results:

Firefox crashes intermittently.

Observed crash stack in WinDbg:

ntdll!wcslen
ntdll!RtlInitUnicodeStringEx
KERNELBASE!LoadLibraryExW
KERNEL32!BaseThreadInitThunk
ntdll!RtlUserThreadStart

Exception:

Access violation - code c0000005

Register values seen at crash time:

rcx = 0000000000000000
rdx = 0000013774120000

du rcx and du rdx show unreadable memory (????????...).

Example stack output:

0:005> k

Child-SP RetAddr Call Site

00 0000002f893ffcf8 00007ffb3ce06a81 ntdll!wcslen+0x74
01 0000002f893ffd00 00007ffb3a740f7c ntdll!RtlInitUnicodeStringEx+0x21
02 0000002f893ffd30 00007ffb3b44e8d7 KERNELBASE!LoadLibraryExW+0x6c
03 0000002f893ffda0 00007ffb3cdec53c KERNEL32!BaseThreadInitThunk+0x17
04 0000002f893ffdd0 0000000000000000 ntdll!RtlUserThreadStart+0x2c

I cannot clearly determine where the fault is. At the moment it does not look like an obvious bug in my own project, because the same DLL can hook other applications without causing crashes.

Expected results:

Firefox should not crash when a third-party DLL is present. If third-party module handling or inspection is involved, Firefox should handle invalid or unexpected DLL/path situations safely instead of crashing.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Bob Owen (:bobowen)]

(In reply to yaziciogludefne from comment #0)
...

I cannot clearly determine where the fault is. At the moment it does not look like an obvious bug in my own project, because the same DLL can hook other applications without causing crashes.

Whether injected DLLs cause issues can be highly dependent on the application you are injecting into.
Have you reported any of the crashes though our crash reporter?
If you have, could you post links please.

I'm not sure how much we can help with your own injection project.

Firefox should not crash when a third-party DLL is present. If third-party module handling or inspection is involved, Firefox should handle invalid or unexpected DLL/path situations safely instead of crashing.

From that stack in the description it looks like it's crashing trying to find the length of the library name, while initialising a UNICODE_STRING.
Which would indicate there is a problem with the name of the DLL.
That is crashing early in Windows code, I believe it's before we do any of our own DLL inspection.
Not clear why that would only crash on Firefox.

Comment 3

[yaziciogludefne]

Thank you for your response.

Below I am sharing a few crash reports with the most frequently observed signatures.

I have not yet been able to find the root cause. The same DLL works without issues in other applications, which makes this behavior in Firefox difficult to understand.

If you have any suggestions on what else I could check or how to narrow this down further, I would really appreciate it.

Thanks again for your help.

https://crash-stats.mozilla.org/report/index/be251536-39e0-4172-826c-ac4e60260330
https://crash-stats.mozilla.org/report/index/9516e558-f805-4f93-a5d3-04d810260327#tab-details
https://crash-stats.mozilla.org/report/index/db285b9e-d97c-4fe1-aa92-1c0ca0260330
https://crash-stats.mozilla.org/report/index/45ae0d9d-a2f1-426d-a9ae-7ed920260330

Comment 4

[yaziciogludefne]

Thank you for your response.

Below I am sharing a few crash reports with the most frequently observed signatures.

I have not yet been able to find the root cause. The same DLL works without issues in other applications, which makes this behavior in Firefox difficult to understand.

If you have any suggestions on what else I could check or how to narrow this down further, I would really appreciate it.

Thanks again for your help.

https://crash-stats.mozilla.org/report/index/be251536-39e0-4172-826c-ac4e60260330
https://crash-stats.mozilla.org/report/index/9516e558-f805-4f93-a5d3-04d810260327#tab-details
https://crash-stats.mozilla.org/report/index/db285b9e-d97c-4fe1-aa92-1c0ca0260330
https://crash-stats.mozilla.org/report/index/45ae0d9d-a2f1-426d-a9ae-7ed920260330

Comment 5

[Bob Owen (:bobowen)]

(In reply to yaziciogludefne from comment #4)
...

https://crash-stats.mozilla.org/report/index/be251536-39e0-4172-826c-ac4e60260330
https://crash-stats.mozilla.org/report/index/9516e558-f805-4f93-a5d3-04d810260327#tab-details
https://crash-stats.mozilla.org/report/index/db285b9e-d97c-4fe1-aa92-1c0ca0260330
https://crash-stats.mozilla.org/report/index/45ae0d9d-a2f1-426d-a9ae-7ed920260330

Three of these appear to be a failure to inject failing on wcslen of the injected binary name.
Possibly the memory that you've mapped is no longer valid for some reason.
It seems to be badly corrupting the dump in some cases.

The second one is a crash in data64.ink, which I'm guessing is your injected binary.
It looks like it is trying to write to an address within its own mapped binary, but the upper 32 bits of the pointer have got corrupted somehow.
Either way these do not appear to be issues with Firefox and since this is unlikely to be affecting other users, I'm going to resolve this as invalid.