1752466 - firefox not opening after KB5008353 was installed (Deadlock caused by WebRoot SecureAnywhere)

Status: VERIFIED FIXED

(External Software Affecting Firefox :: Other, defect)

Description

[anew_phase]

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

Steps to reproduce:

installed windows 11 update KB5008353. After that firefox might open on first power up, then would hang and would not open. Removed and reloaded FireFox, same problem. Remove KB5008353. Fire fox is now working

Actual results:

Information and suggestions are @
"https://support.mozilla.org/en-US/questions/1365962?utm_campaign=questions-reply&utm_source=notification&utm_medium=email#answer-1478688"

Expected results:

DUH ... should work with Windows 11 KB5008353

Comment 1

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

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

Comment 2

[Stephen A Pohl [:spohl]]

I have not been able to reproduce this. Could you clarify what you mean by "hang and would not open"? Does Firefox start hanging after a while of being open? Or does it not even start in the first place?

Comment 3

[anew_phase]

Desktop-911651B HP all in one 24-df0xxx
Windows 11 Don't know the build
these updates were install KB5008353 (1/26/22)/KB5009566(1/26/22)/KB5008880(1/12/22)/KB4023057(1/12/22)/KB5008295(1/12/22)/
KB5007040(1/12/22) had the problem on 1/26/22. Uninstalled /KB5008353(1/28) now OK
After the initial power up and perhaps firefox opens then I close it. When I clicked on shortcut or went to program files and clicked on the firefox.exe, Task manager showed Firefox 0% CPU/about 2.1 MB memory and did not change. No window opened and if I clicked firefox again I would get another task with 0% and about the same memory. Each time I clicked shortcut I got another task, but no window. Shortcut showed a check mark and then for a short time the rotating icon.

as an aside, It might have opened a blank window once or twice, but no address bar to enter a URL (I did not check task manager)

Hope this helps,
Tom

Comment 4

[Stephen A Pohl [:spohl]]

Would you be willing to reinstall KB5008353 to further investigate? I'm afraid without a system that can reproduce this issue we have very little to go on.

Comment 5

[anew_phase]

Not tonight, it is 12:30 AM. I have commitment today till noon. After noon I can do it.

Tom

Comment 6

[anew_phase]

Tell me what you want, like a dump or file ( and instructions), and If I can, I'll do it in the morning EST. Otherwise it will be the afternoon

Comment 7

[Stephen A Pohl [:spohl]]

A good first start would be to work through the suggestions in this article:

https://support.mozilla.org/en-US/kb/firefox-hangs-or-not-responding

Depending on whether or not any of those suggestions work, we may have to investigate further.

Comment 8

[anew_phase]

I reinstalled KB5008353 and the problem is back. If I restart windows and use the shortcut, the firefox window opens, but will not go to yahoo/bing/google or other book marks. Task manager shows firefox(5) in the Apps section. I closed Firefox (FF) and restart using the shortcut. Shortcut has a checkmark and rotating icon then they disappear. Task manager shows FF in background process 0%/2.1MB, no window. If I try to activate FF again FF tasks are added to background processes. I tried a crash dump to collect the status for you, but after 30 minutes the progress never left 0%, so I restarted windows.

Regarding your suggestions "https://support.mozilla.org/en-US/kb/firefox-hangs-or-not-responding" none are my symptoms and after spending all day yesterday doing unrelated suggestion, I think I'll pass on these. My fix is to remove the update.

Perhaps BestBuy or HP has the same configuration as mine , probably for less than I paid. That might help recreate the problem. If you want a file or dump, let me know before 11:30 EST, because I will remove the update at that time.

Regards,
Tom

Comment 9

[Stephen A Pohl [:spohl]]

Could you collect a minidump of the hanging Firefox processes via Task Manager and attach them to this bug before you uninstall the Windows update?

Comment 10

[anew_phase]

WOW, I just came back and FF opened all the way and update is still installed. Closed it and it now does not open again.

Tell me how to do the dump you request

Comment 11

[Stephen A Pohl [:spohl]]

1. Open Task Manager
2. Expand Firefox in the list of processes
3. For each process, right click and select "Create dump file"
4. Attach each dump file to this bug

Thanks!

Comment 12

[anew_phase]

I have noticed FF responds different if I login after my wife has logged out. one time FF opened and then went to my home setting, my yahoo mail. Another time it opened, but did not open mail and I could not get to the internet.

Got files, but don't see how to attach them.

Comment 13

[Robert Longson [:longsonr]]

scroll up and look for the Attach New File button on this page.

Comment 14

[anew_phase]

found how to attach. getting file size error they are 171 MB only 10 allowed. do you have an email I can send to or an ftp site (if ftp still exist)?

Comment 15

[Stephen A Pohl [:spohl]]

I have just sent you a file request to your email address. Let me know if that doesn't work. Thanks!

Comment 16

[anew_phase]

Sent 3 dumps all static 0% CPU/about 2.1MB Memory.

I have another dump that was changing its memory usage but it is 470 MB and your account does not have enough space right now. Let me know when you clear it and I will forward this one to you. No obvious FF operation differences, but it was using resources differently than the other three.

Tom

Comment 17

[Stephen A Pohl [:spohl]]

There should be enough space now for the fourth one. Thanks!

Comment 18

[anew_phase]

What info do you need?

Comment 19

[Stephen A Pohl [:spohl]]

Do you have WebRoot SecureAnywhere installed? Would you be able to temporarily uninstall it and see if this resolves this issue for you?

Comment 20

[anew_phase]

I do have it installed. I did not install it. It was done by Geek Squad as part of my support contract. If I uninstall it, will I need to contact them to reinstall it?

If not, give me detailed instruction on how to uninstall it and then reinstall it.

Comment 21

[Stephen A Pohl [:spohl]]

It may be sufficient to disable it. I'm not familiar with this software myself, but it should give you an option to temporarily disable it.

Comment 22

[anew_phase]

removing the webroot protection resolved the problem.

Comment 23

[Stephen A Pohl [:spohl]]

(In reply to anew_phase from comment #22)

removing the webroot protection resolved the problem.

Thanks for confirming!

Toshi, :handyman mentioned that this was in your wheelhouse. Could you take a look at this bug? I'm also going to share the minidumps with you so you can take a look. Thank you!

Comment 24

[Toshihito Kikuchi [:toshi]]

The provided dumps indicate the process was in deadlock. Our main thread called GetShellFolderPath, which started delayloading shcore.dll in a different thread, which was hooked by Webroot (wrusr.dll), which called SHGetFolderPathW, which eventually hit a lock that is owned by our main thread. We can at least block wrusr.dll, but let's see what else we can do. I've never seen delayload spawned a new thread like this. This might be a new behavior in Win11.

Comment 25

[Toshihito Kikuchi [:toshi]]

I installed WebRoot and analyzed its behavior. WRusr.dll is injected via CreateRemoteThread + LoadLibrary.

My earlier analysis was a bit wrong. Our main thread, which tried to load shcore.dll, was waiting for a loader lock. The other thread was spawned by WebRoot to load WRusr.dll. There was no hook. This deadlock was caused by a race between our main thread, which owns a lock in windows.storage.dll and waits for a loader lock, and WebRoot's thread, which owns a loader lock first and then waits for the lock in windows.storage.dll. The problem is in WRusr.dll. Calling SHGetFolderPathW in DllMain is not a good idea.

.  0  Id: bac.4c0 Suspend: 0 Teb: 00000069`be4f2000 Unfrozen ""
 # Child-SP          RetAddr               Call Site
00 00000069`bedfe1b8 00007ffe`21c7145e     ntdll!NtWaitForSingleObject+0x14
01 00000069`bedfe1c0 00007ffe`21c5b931     ntdll!LdrpDrainWorkQueue+0x15e
...
07 00000069`bedfed30 00007ffe`1d46b641     windows_storage!_delayLoadHelper2+0x32
08 00000069`bedfed70 00007ffe`1d35442d     windows_storage!_tailMerge_shcore_dll+0x3f
09 00000069`bedfede0 00007ffe`1d3538e2     windows_storage!kfapi::CFolderCache::GetPath+0x91d
0a 00000069`bedfefc0 00007ffe`1d348109     windows_storage!kfapi::CKFFacade::GetFolderPath+0xc2
0b 00000069`bedff070 00007ffd`cdc5ce93     windows_storage!SHGetKnownFolderPath+0x99
0c 00000069`bedff240 00007ffd`cdc5cd56     xul!GetShellFolderPath+0x33
0d 00000069`bedff2a0 00007ffd`cca6b289     xul!nsXREDirProvider::GetUserDataDirectoryHome+0x86
0e 00000069`bedff330 00007ffd`cdc556ba     xul!nsXREDirProvider::GetUserDataDirectory+0x99
0f (Inline Function) --------`--------     xul!nsXREDirProvider::GetUserAppDataDirectory+0x7
10 00000069`bedff4a0 00007ffd`d0e71a7d     xul!XREMain::XRE_mainInit+0x44a

   4  Id: bac.75c Suspend: 0 Teb: 00000069`be4fc000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 00000069`bfdfeee8 00007ffe`21c8a2da     ntdll!NtWaitForAlertByThreadId+0x14
01 00000069`bfdfeef0 00007ffe`1f20d449     ntdll!RtlSleepConditionVariableCS+0x10a
02 00000069`bfdfef60 00007ffe`1d46d89a     KERNELBASE!SleepConditionVariableCS+0x29
03 00000069`bfdfef90 00007ffe`1d354408     windows_storage!Init_thread_header+0x2a
04 00000069`bfdfefc0 00007ffe`1d3538e2     windows_storage!kfapi::CFolderCache::GetPath+0x8f8
05 00000069`bfdff1a0 00007ffe`1d41b715     windows_storage!kfapi::CKFFacade::GetFolderPath+0xc2
06 00000069`bfdff250 00007ffe`0aafdf36     windows_storage!SHGetFolderPathW+0x1e5
07 00000069`bfdff440 00007ffe`0aafedcf     WRusr!DllRegisterServer+0x476
08 00000069`bfdff570 00007ffe`0aaff5db     WRusr!SynExp+0x3f
09 00000069`bfdff5c0 00007ffe`21c5fd17     WRusr!SynExp+0x84b
0a 00000069`bfdff620 00007ffe`21c92bce     ntdll!LdrpCallInitRoutine+0x6b
...
10 00000069`bfdffab0 00007ff6`37af8abe     ntdll!LdrLoadDll+0x106
11 (Inline Function) --------`--------     firefox!mozilla::interceptor::FuncHookCrossProcess<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyUnique<mozilla::interceptor::MMPolicyOutOfProcess> >,long (*)(wchar_t *, unsigned long *, _UNICODE_STRING *, void **)>::operator()+0x19
12 00000069`bfdffba0 00007ffe`1f1e3f02     firefox!mozilla::freestanding::patched_LdrLoadDll+0x1ae
13 00000069`bfdffc80 00000218`65c0002f     KERNELBASE!LoadLibraryExW+0x172 <<<< Spawned by WebRoot to load WRusr.dll
14 00000069`bfdffcf0 00000000`00000000     0x00000218`65c0002f

I'm not sure why installing KB5008353 triggered this. I could not reproduce the deadlock on my Win11 + KB5008353 + WebRoot. I think this is a timing issue and not limited to Win11 + KB5008353.

Comment 26

[Toshihito Kikuchi [:toshi]]

Firefox already contains a logic to prevent this injection technique for years, but it's been enabled only in Nightly. This case is a good reason to enable it for all channels. We already have Bug 1481454. I confirmed WRusr.dll was not injected into Nightly on my end. So I believe Nightly does not have this problem.

Tom, glad to hear removing WebRoot resolved the problem. If you reinstall WebRoot, could you install Nightly and see if it can coexist with WebRoot? I'll get Bug 1481454 done anyway.

Comment 27

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

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

Comment 28

[anew_phase]

Not sure what you want, but I have spent a lot of time getting Mozilla the information to resolve the situation.

"I'm not sure why installing KB5008353 triggered this. I could not reproduce the deadlock on my Win11 + KB5008353 + WebRoot. I think this is a timing issue and not limited to Win11 + KB5008353."

I have provided my configuration, so why not go out and purchase one or borrow one from HP.

I have no idea what nightly is and the amount of work that goes into installing it.

Comment 29

[Stephen A Pohl [:spohl]]

(In reply to anew_phase from comment #28)

Not sure what you want, but I have spent a lot of time getting Mozilla the information to resolve the situation.

"I'm not sure why installing KB5008353 triggered this. I could not reproduce the deadlock on my Win11 + KB5008353 + WebRoot. I think this is a timing issue and not limited to Win11 + KB5008353."

I have provided my configuration, so why not go out and purchase one or borrow one from HP.

I have no idea what nightly is and the amount of work that goes into installing it.

We appreciate your help here. As I'm sure you will understand, we can't possibly "go out and purchase" every system that shows an issue.

Installing Nightly is very easy. You can download it here and install/uninstall it just like regular Firefox: https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly

"Nightly" simply refers to Firefox that gets updates on a nightly basis, as opposed to the stable version of Firefox that is updated less frequently.

If you could install Nightly and verify that it runs normally with Win11 + KB5008353, it would help confirm Toshi's analysis. Thanks again for your help!

Comment 30

[anew_phase]

OK I downloaded it and before I reinstall the update, is there any thing I have to do (like reboot or stop FF and restart)? Is there a way to make sure I am using nightly and not my standard edition? Reinstalling testing and uninstalling is time consuming, so I want to have the correct configuration before I go through the test. If it doesn't work do you want dumps? PLEASE cover all the bases.

Comment 31

[anew_phase]

if you want dumps, make sure your storage site is clear

Comment 32

[Stephen A Pohl [:spohl]]

Yes, go ahead and install Nightly. When you launch it, you will see a different icon in your task bar so you can identify if you're running Nightly or stable Firefox.

1. You can install Nightly before or after installing the Windows update, it shouldn't make a difference.
2. Make sure you have WebRoot installed and enabled as before when you reported the issue.
3. Once you have KB5008353 and Nightly installed, start regular Firefox and try to reproduce the hang. Hopefully, it will hang as before when you first reported this bug.
4. Then, close Firefox and start Nightly. Check whether or not the issue reproduces.

If, for whatever reason, you can reproduce the hang in Nightly, please collect the minidumps as before for Nightly. The storage is cleared and should have plenty of space to upload the minidumps.

Thank you!

Comment 33

[anew_phase]

I down loaded it, But the ICON looks the same. so I guess I didn't do it correctly

Comment 34

[anew_phase]

DO I have to close FF

Comment 35

[Toshihito Kikuchi [:toshi]]

(In reply to anew_phase from comment #34)

DO I have to close FF

No, you don't have to close the current version. You can open Firefox and Nightly at the same time.

Can you please download Nightly installer from https://download-origin.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-central/firefox-98.0a1.en-US.win64.installer.exe and try it again?

Comment 36

[anew_phase]

OK got it and it seems to correct the problem, but it is poker night and I didn't have much time to check it out. IT looks like I have to set up the bookmarks and see if they work.

I am in the dog house because I left the system with the update in and my wife's FF hung. I am now on the &^% list.

Comment 37

[anew_phase]

Installed update and tested Nightly, it opened and accessed the internet. I tried it a couple of time. Remove the update and back to using original FF.

Comment 38

[Toshihito Kikuchi [:toshi]]

Thank you for testing Nightly! It's really good news that you didn't hit this issue with Nightly. I updated bug 1481454 with a patch.

Comment 39

[anew_phase]

You're welcome. Let me know when the fix get into the release, so that I can install the update.

Comment 40

[jscher2000]

On SUMO, Windows 10/11 users are reporting Webroot problems with 64-bit Firefox 97 release:

• https://support.mozilla.org/questions/1367248
• https://support.mozilla.org/questions/1367301

We might need an uplift to release on bug 1481454 if it's deemed safe enough.

Comment 42

[Stephen A Pohl [:spohl]]

Closing this as fixed in 98 since that's where bug 1481454 landed. Firefox 98 is scheduled to be released on 3/8. Adding RyanVM for awareness in the event that we'd want to roll this into a possible dot release.

Comment 43

[Dalacor]

Does this mean we need to download Firefox 98 beta manually or will there be a plan to release a Firefox 97.0.1 patch that includes whatever version 98 includes to fix the issue with Webroot?

Is the issue with Webroot or with Firefox? Thank you.

Comment 44

[Stephen A Pohl [:spohl]]

The issue is with WebRoot (see comment 24 and comment 25 for the technical background). Firefox 98 Beta has a patch that prevents the problem that you are welcome to download for now. Ryan will be able to give input on whether or not there are plans to release a dot release for Firefox 97.

Comment 45

[Dalacor]

I think this is a timing issue and not limited to Win11 + KB5008353.

I can confirm that this is not a Windows 11 issue nor a windows update issue as our machines are Windows 10 and get their updates from WSUS which has not had any updates applied in the last week or two. The problem apparently also started last night.

I will wait to hear back from Webroot and see what they have to say as well. But if necessary I can deploy Firefox 98 beta if there is no plans to release a dot version for 97. Thank you.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Yeah, this sounds tied to an update pushed out by Webroot. Unfortunately, bug 1481454 seems like a really scary change to take into a dot release with minimal testing on Beta first given the unknowns around what other fallout it may incur with other programs that hook into Firefox. I think we should try to get in touch with Webroot first to see if they can roll back whatever change they shipped to their software which is interacting badly with Firefox.

Johnny, are you still involved with Webroot and if so, would you be able to help get this in front of the right people?

Comment 47

[Dalacor]

I will add that the issue seems to affect only Firefox 97. Downgrading to Firefox 96.0.3 fixed the issue when I was troubleshooting the problem. It appears to be specific to Firefox 97, especially given that other users in the posts that I linked report issues with version 97. I believe that something in Firefox 97 and Webroot don't work well together.

I wonder if the original OP only experienced the problem in FF 96 because he is running Windows 11? On our W10 machines that are affected, either running FF 97 in compatibility mode (win 8) or reverting to FF 96.0.3 or uninstalling webroot resolved the issue. I have no users reporting problems running the previous version of Firefox. Our problems only started with version 97. But I do agree that Webroot is the cause but linked to Windows 11 for the OP and in our case linked to version FF 97 which has W11 functionality?

But not all our machines running FF 97 are affected. Only some. No idea why. I have posted this topic with Webroot and I will advise you of their response.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

I've left a comment in the Webroot support thread too.

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Let's reopen this while we continue to investigate a fix for this from the Webroot end.

Comment 50

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx97 release notes as a known issue.

Users running WebRoot SecureAnywhere Antivirus may experience impaired functionality when upgrading to Firefox 97. Closing WebRoot will allow Firefox to resume normal operation.

Comment 51

[Johnny Shaw]

Sorry Ryan I no longer work for Webroot. But I will forward this thread to someone who still work there.

Comment 52

[Johnny Shaw]

My 2c, WRusr should avoid calling APIs from DllMain that could conflict with initialization. Anything in the context of DllMain that could conflict with the loader is risky - in this case it's triggering a wait on a resolving an import in a delayed load. Which won't occur since the loader is currently servicing the WRusr loading.

Comment 53

[Dalacor]

I have received a reply from Webroot.

Thank you for your reply and for providing the logging. This issue was presented in Firefox's v97 and there appears to be a fix that will be in place for version 98. At this time, we are monitoring and tracking this issue. For some customers, doing an uninstall and reinstall has worked and for others disabling the Web Shield with a reboot has also worked as a temporary workaround.

I have provided them with Webroot logs and provided them with this bug report and the post on their forum relating to this issue. They seem to be still be at the stage of thinking this is a Firefox 97 problem despite the fact that uninstalling and re-installing Webroot seems to fix the problem - which obviously points to Webroot being the cause.

I have also said to them that Firefox 98 is a beta version, not meant to be released to the public and will only actually be released as stable in four weeks time.

I will update you when I get more information from Webroot. Thanks

Comment 54

[Toshihito Kikuchi [:toshi]]

Johnny's comment 52 is right. I made a PoC to prove calling SHGetFolderPathW in DllMain can cause a deadlock. This proves this is not a problem on Firefox side.

The reason is that windows_storage!kfapi::CFolderCache::GetPath owns a critical section and then starts delayloading shcore.dll as shown below. Preloading shcore.dll may resolve this deadlock, but in general, DllMain should not call this kind of expensive APIs.

Here's the flow of this deadlock.

1. FF's main thread calls GetShellFolderPath and owns the critical section
2. FF's main thread starts delayloading shcore.dll
3. WebRoot spawns a thread in FF that loads WRusr.dll
4. WRusr.dll's DllMain calls SHGetFolderPathW
5. WRusr.dll's DllMain waits for the critical section that is owned by FF's main thread
6. FF's main thread waits until loading shcore.dll is completed, but it's never completed because WRusr.dll's DllMain is running

windows_storage!kfapi::CFolderCache::GetPath+0xd0:
00007ffc`4d68f6c0 89542440        mov     dword ptr [rsp+40h],edx
00007ffc`4d68f6c4 498d742458      lea     rsi,[r12+58h]
00007ffc`4d68f6c9 488bce          mov     rcx,rsi
00007ffc`4d68f6cc 48ff155ddc5000  call    qword ptr [windows_storage!_imp_EnterCriticalSection (00007ffc`4db9d330)]
    ----> probably this is to protect a global counter below
00007ffc`4d68f6d3 0f1f440000      nop     dword ptr [rax+rax]
00007ffc`4d68f6d8 418b4c2418      mov     ecx,dword ptr [r12+18h]
00007ffc`4d68f6dd 48ff152cf06600  call    qword ptr [windows_storage!_imp_SHGlobalCounterGetValue (00007ffc`4dcfe710)]
    ----> delayloads shcore.dll
00007ffc`4d68f6e4 0f1f440000      nop     dword ptr [rax+rax]
00007ffc`4d68f6e9 413944241c      cmp     dword ptr [r12+1Ch],eax
00007ffc`4d68f6ee 0f85a10a0000    jne     windows_storage!kfapi::CFolderCache::GetPath+0xba5 (00007ffc`4d690195)

windows_storage!kfapi::CFolderCache::GetPath+0x104:
00007ffc`4d68f6f4 4032ff          xor     dil,dil

windows_storage!kfapi::CFolderCache::GetPath+0x107:
00007ffc`4d68f6f7 418944241c      mov     dword ptr [r12+1Ch],eax
00007ffc`4d68f6fc 418b4c2420      mov     ecx,dword ptr [r12+20h]
00007ffc`4d68f701 48ff1508f06600  call    qword ptr [windows_storage!_imp_SHGlobalCounterGetValue (00007ffc`4dcfe710)]
...
windows_storage!kfapi::CFolderCache::GetPath+0xba5:
00007ffc`4d690195 40b701          mov     dil,1
00007ffc`4d690198 e95af5ffff      jmp     windows_storage!kfapi::CFolderCache::GetPath+0x107 (00007ffc`4d68f6f7)

Comment 55

[Toshihito Kikuchi [:toshi]]

Attachment: PoC - DLL's code

Comment 56

[Toshihito Kikuchi [:toshi]]

Attachment: PoC - EXE's code

Comment 57

[Toshihito Kikuchi [:toshi]]

It's possible that one of our recent patches changed the time when we load shcore.dll, but even if so, it's not a regression from that change.

Comment 58

[James Morgheim]

Greetings all. The engineering team at Webroot is actively investigating this issue and putting together a plan of action to address this as quickly as possible. I greatly appreciate all the context given in this discussion as it gives us a clear path to reproduction and has highlighted the areas of concern for us to address in future releases. I will post updates to this thread as things progress on our side.

Comment 63

[Toshihito Kikuchi [:toshi]]

Attachment: bug1752466-block-webroot-secureanywhere

Comment 64

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1752466 - Block WRusr.dll to stop the deadlock issue. r=haik

Comment 65

[anew_phase]

looks like you have a conflict with the latest update "2022-02 Cumulative Update for Windows 11 for x64-based Systems (KB5010386)"

This is a security update and I am leaving firefox and going to edge and reinstall the updates.

Firefox opened but could not access the web

Comment 66

[Stephen A Pohl [:spohl]]

(In reply to anew_phase from comment #65)

looks like you have a conflict with the latest update "2022-02 Cumulative Update for Windows 11 for x64-based Systems (KB5010386)"

This is a security update and I am leaving firefox and going to edge and reinstall the updates.

Firefox opened but could not access the web

Are you referring to a new issue that you're encountering? Are you still running WebRoot? If so, note that a fix for this issue hasn't landed yet, so you are quite likely running into the same problem as reported here.

Comment 67

[anew_phase]

New window's update ... same issue. KB5008353 not installed and have the same conflict with KB5010386

Comment 68

[Stephen A Pohl [:spohl]]

(In reply to anew_phase from comment #67)

New window's update ... same issue. KB5008353 not installed and have the same conflict with KB5010386

Right, we've determined that this issue is not related to a particular Windows update. WebRoot is working on a fix and based on the patch in this bug, it appears that we will be rolling out a preventative workaround as well.

Comment 69

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ad3fd5a6da6
Block WRusr.dll to stop the deadlock issue.  r=haik

Comment 70

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/6ad3fd5a6da6

Comment 71

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta and Release approval.

Comment 72

[Toshihito Kikuchi [:toshi]]

Comment on attachment 9263763 [details]
Bug 1752466 - Block WRusr.dll to stop the deadlock issue. r=haik

Beta/Release Uplift Approval Request

• User impact if declined: If WebRoot SecureAnywhere is installed, Firefox may enter a deadlock.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a config-only change, adding a new entry to the blocklist we've been using for years. The risk is low.
• String changes made/needed:

Comment 73

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9263763 [details]
Bug 1752466 - Block WRusr.dll to stop the deadlock issue. r=haik

Dot release driver, approved for 98.0b5.

Comment 74

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f91f2c4a17a5

Comment 75

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9263763 [details]
Bug 1752466 - Block WRusr.dll to stop the deadlock issue. r=haik

Approved for 97.0.1 to stop the bleeding for now. For the WebRoot people following this bug, this block only applies to the current version of WRusr.dll. Newer releases (presumably containing whatever fix y'all end up shipping) should be unaffected by this change.

Comment 76

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/b881a697c484

Comment 77

[Ryan VanderMeulen [:RyanVM]]

Added to the 97.0.1 release notes.

Works around problems with WebRoot SecureAnywhere antivirus rendering Firefox unusable in some situations

Comment 78

[Dalacor]

Thank you to the Mozilla team for releasing an update to address the issue. Looking forward to Firefox 97.0.1 coming out. Much appreciated.

I must admit I am a bit surprised at the very slow response and lack of communication from Webroot in addressing this issue given the severity of the impact on Firefox and as result the Internet. It has been over a week since this was reported to Webroot. I would have thought that they would have made this a priority to address.

Anyway thanks to the Mozilla guys for releasing a Firefox version that works round the issue. You are stars.

Comment 79

[Marcel]

Yes, good job indeed ! Everyone using Webroot should open tickets, this is what I just did, if they get zillion tickets on the same subjets, they might put a bit more efffort in handing their product. Cheers !

Comment 80

[Ryan VanderMeulen [:RyanVM]]

We've started the rollout of the 97.0.1. If you have automatic updates enabled, you should receive it automatically within the next couple days. Otherwise, you can manually check for updates via the steps below. We'd love some confirmation from affected users that the workaround is effective!
https://support.mozilla.org/kb/update-firefox-latest-release

Comment 81

[Marcel]

I had the issue on my main machine, I just updated to the new version and everything runs well. Congrat to the dev team !

Comment 82

[Dalacor]

On the test machine that I left unfixed for troubleshooting purposes, I have updated to Firefox 97.0.1 and am pleased to report that this definitely fixes the issue. Firefox runs snappily after updating! Well done.

Comment 83

[anew_phase]

97.0.1 Worked for me.

Comment 84

[Stephen A Pohl [:spohl]]

Marking as verified based on comment 81, comment 82 and comment 83. Thanks, all, for confirming.

Comment 85

[James Morgheim]

Thanks to all for surfacing this issue and providing such great details for the Webroot team to analyze. We have identified a fix for this issue and will be including the changes as part of the next agent release. Thank you for your patience as we worked through the problem.

Comment 86

[Dalacor]

I have opened a new bug report - https://bugzilla.mozilla.org/show_bug.cgi?id=1763683 as I am now using Firefox ESR version. Unfortunately this problem has occurred again with Firefox 91.8.0 ESR. As advised in the new bug post, I have uninstalled Webroot and this seems to fix the issue. Not sure why the ESR is affected as I assume that whatever fixes you applied to Firefox 97.0.1 would apply to 91.8.0 ESR?

I have filed a report with Webroot as it's very concerning that Webroot is continuing to cause problems with Firefox. I don't know if the cause is the same as this specific bug report, but I have uploaded a Firefox dump file on the new bug report. Thank you.

Comment 87

[Gian-Carlo Pascutto [:gcp]]

Not sure why the ESR is affected as I assume that whatever fixes you applied to Firefox 97.0.1 would apply to 91.8.0 ESR?

Only security fixes get backported to ESR.

In this case in particular, a more fundamental mitigation for third-party applications causing Firefox to crash like this, that we shipped in Firefox 99, actually caused an issue for enterprise installations that were doing this intentionally: https://bugzilla.mozilla.org/show_bug.cgi?id=1757487

When dealing with third-party stuff unfortunately fixing the breakage of one product sometimes makes another start crashing Firefox. It's very messy.

Comment 89

[Haik Aftandilian [:haik]]

[Tracking Requested - why for this release]:
Report of the bug likely causing ESR startup issues on bug 1763683.

Comment 90

[Haik Aftandilian [:haik]]

(In reply to James Morgheim from comment #85)

Thanks to all for surfacing this issue and providing such great details for the Webroot team to analyze. We have identified a fix for this issue and will be including the changes as part of the next agent release. Thank you for your patience as we worked through the problem.

Hi James, do you have an estimate for when the fix will be available?

Comment 91

[James Morgheim]

(In reply to Haik Aftandilian [:haik] from comment #90)

(In reply to James Morgheim from comment #85)

Thanks to all for surfacing this issue and providing such great details for the Webroot team to analyze. We have identified a fix for this issue and will be including the changes as part of the next agent release. Thank you for your patience as we worked through the problem.

Hi James, do you have an estimate for when the fix will be available?

Hello Haik, we have a fix going out with our next agent release version which will begin slow distribution to our consumer customers on Monday April 25th. We expect this slow distribution process to take approximately six weeks before it will be live to all consumer customers. Hope this helps, and thanks to all for their patience while we worked through the issue.

Comment 92

[Ryan VanderMeulen [:RyanVM]]

Happy to take this on ESR also if we get an uplift request.

Comment 93

[Haik Aftandilian [:haik]]

Comment on attachment 9263763 [details]
Bug 1752466 - Block WRusr.dll to stop the deadlock issue. r=haik

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The issue is causing Firefox ESR to fail to launch for users that have the WebRoot anti-virus product. WebRoot is rolling out a fix (but we have not verified it at this time) and they estimate it will take about 6 weeks to reach all users.
• User impact if declined: Users running ESR with the WebRoot anti-virus product installed may not be able to launch Firefox until they uninstall WebRoot. (Alternatively, users could use Release.)
• Fix Landed on Version: 97
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is a DLL blocklist change only.

Comment 94

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9263763 [details]
Bug 1752466 - Block WRusr.dll to stop the deadlock issue. r=haik

Approved for 91.9esr.

Comment 95

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/118a67d861fc

Comment 96

[Ryan VanderMeulen [:RyanVM]]

Dalacor, can you please confirm that the 91.9esr RC build is working better for you? Thanks in advance!
https://archive.mozilla.org/pub/firefox/candidates/91.9.0esr-candidates/build1/win64/en-GB/

Comment 97

[Dalacor]

Unfortunately I am unable to test the issue. If you uninstall Webroot and re-install it, this seems to fix the problem. I had to do that as Firefox was unusable. For some reason none of my clients have reported having this issue, which is odd as many of them had this issue when we were using Firefox Rapid Release 97. But if I come across another machine experiencing the issue, I will test it out and let you know.

However, I can confirm that whatever fix you applied in Firefox 97.0.1 worked for us on a machine experiencing the issue. So if it's the same fix as in mainstream version, then it will definitely fix the issue for ESR. Thank you.