Been pulling my hair out debugging a relative’s persistent BSOD (once every ~6hrs) after nudging them to take the first degoogling step by switching browsers. I could not believe at first that a user space program,…

6 points•xeonmc•8 days ago•3 comments•
Been pulling my hair out debugging a relative’s persistent BSOD (once every ~6hrs) after nudging them to take the first degoogling step by switching browsers.

I could not believe at first that a user space program, especially a Windows Store sandboxed one, could affect anything in the kernel, but analyzing every single coredump shows the exact same trigger: Firefox attempted to rename the UrlAssocistions/http registry key in the UWP sandbox’s virtualized registry hive, triggering an access violation in the Registry system service and crashing ntoskrnl.

It turns out that there is a secretly enabled config “browser.shell.setDefaultBrowserUserChoice.regRename” that causes Firefox to attempt this renaming periodically despite the user already having unchecked the “check if default on startup” option. A quick search reveals that it was a vestigial A/B testing feature that was already slated for deprecation[0], but remained in the current version and a perfect storm of I’m guessing UWP kernel memory bug and Firefox dark pattern triggered this outcome.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=2060861

3 comments

et-duckyabout 21 hours ago
For free family support I'd be backing up files and reimaging before digging that deep.
Zeetah8 days ago
I would love to read about how you figured this out.
xeonmc4 days ago
WinDbg to analyze the core dump to pinpoint the process that triggered the offending syscall, then reproducing the problem via the advanced config flag.

Read the full thread on Hacker News →

Related stories