1758077 - Crash in [@ @0x0 | nsAppShell::ProcessNextNativeEvent]

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect, P3)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/69a93500-e27d-4c5e-9610-5eab70220304

Reason: EXCEPTION_ACCESS_VIOLATION_EXEC

Top 10 frames of crashing thread:

0 None @0x0000000000000000 
1 xul.dll nsAppShell::ProcessNextNativeEvent widget/windows/nsAppShell.cpp:731
2 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1111
3 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:107
4 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324
5 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
6 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
7 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:603
8 xul.dll nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:295
9 xul.dll XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:5349

This is a really odd crash:

• The locale is almost invariably it even though it's happening on several different pages. I think this may be down to an organization with a specific Firefox setup. I know that Firefox is used in Italy's public sector so that might explain this correlation.
• Almost all crashes have the wups.dll library in the module list but it's always been unloaded at the point where we crash.
• We're always trying to execute a NULL pointer.
• The crashes largely seem to come from version 97.0.1, previously they came from 92.0.1. This again makes it look like some kind of enterprise deployment where everyone is on the same (arbitrary?) version.

This makes me think that we're trying to run something that comes from wups.dll, that DLL gets unloaded for some reason and we crash, with the local setup probably being the culprit.

Comment 1

[Toshihito Kikuchi [:toshi]]

Interesting. The call to TranslateMessage in nsAppShell::ProcessNextNativeEvent ended up executing the null address.

TranslateMessage has two indirect jumps to poi(user32!_imp_NtUserTranslateMessage) and user32!gImmApiEntries+0x160. The latter address is first filled with user32!DefaultPreDispatchProc, but it's replaced with IMM32!ImmTranslateMessage when user32.dll loads imm32.dll. Maybe that replacement failed for some reason (related to wups.dll)..?

(In reply to Gabriele Svelto [:gsvelto] from comment #0)

This makes me think that we're trying to run something that comes from wups.dll, that DLL gets unloaded for some reason and we crash, with the local setup probably being the culprit.

Wups.dll is still loaded in the dumps. And there are a couple of sleeping threads running wups.dll's code. Because minidump did not capture its resource section, we couldn't solve debug information. Wups.dll is a system DLL related to Windows Update.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.