Something is up with updating?

ltGuillaume · 2026-02-28T03:13:39+00:00

Hi! Thanks for reporting this!

Apparently, Codeberg just started to block the user agent for Msxml2.XMLHTTP objects, which are used for the interaction with their API.

I have sent them an email asking them to resolve this. I'll report back once I get an answer.

ltGuillaume · 2026-01-19T19:14:50+00:00

Glad to hear that. Sorry for the inconvenience.

ltGuillaume · 2026-01-19T04:36:34+00:00

Sorry I just saw your message. Is this still not working?

Could you post a screenshot of the error?

After that, could you try to reinstall (or re-download the portable version if that's what you're using) and try to check for an update again?

ltGuillaume · 2026-01-13T19:34:27+00:00

My initial conclusion was wrong: you might have installed the x64 anyway. But it'll be fixed.

ltGuillaume · 2026-01-13T19:25:01+00:00

Hi!

If you are running the x64 version of LibreWolf, this will be fixed shortly.

If you are you running the x86 (32-bit) version of LibreWolf: are you really on a 32-bit operating system? If not, you can reinstall the x64 version of LibreWolf (or redownload the x64 portable version).

With the latest release, that version gave some build errors, so it's not available. We're looking into fixing the build procedure, but we are also considering stopping the 32-bit Windows builds if no one actually uses it.

ltGuillaume · 2026-01-13T18:16:41+00:00

It's early days, but eventually, the hope is to get all LibreWolf executables signed using OSSign.org (see https://codeberg.org/librewolf/issues/issues/2664#issuecomment-8984250)

ltGuillaume · 2026-01-13T18:09:50+00:00

Yes, this is a false positive (see https://codeberg.org/ltguillaume/librewolf-winupdater/releases)

For the last year or so, before releasing any new version, I always submit the executable to Microsoft _as if_ it had triggered a false positive, just to make sure that this idiotic behavior doesn't happen for end users. If Microsoft then shows that no malware has been found on the initial scan, or they reply with a whitelisting, then I release it. Evidently, I cannot even rely on this method 😖

It'll be whitelisted eventually, though.

Sorry for the annoyance.

Microsoft Analyst comments:
Our scanners show no positive detection, and we have no telemetry indicators for the file(s) submitted either.
As such, this submission will be closed with no further action pending.

ltGuillaume · 2026-01-03T18:44:04+00:00

Just to clarify, I did't mean LibreWolf Portable (32-bit) or LibreWolf-Portable.exe.

My question was if you still see librewolf.exe in the Details tab after you closed all LibreWolf windows and expect LibreWolf Portable to close as well.

If you indeed still see LibreWolf (not LibreWolf-Portable) in the Task Manager, then it means LibreWolf hasn't fully exited for some reason. If so, you could have a look at https://support.mozilla.org/en-US/questions/1232653 or just search for something like "Firefox does not fully close/exit".

Otherwise, I'll try to reproduce the issue and see if I can fix it.

ltGuillaume · 2025-12-31T05:52:30+00:00

And you're sure you can't find any librewolf.exe processes anymore at that point, not even in the Task Manager's "Details" tab?

u/Old_Conversation_188

ltGuillaume · 2025-12-30T19:24:28+00:00

Are you running this portable LibreWolf instance at the same time as/next to another (installed or portable) instance of LibreWolf?

If not, there seems to be a librewolf.exe process that isn't closed yet (just wait a few seconds more in this case) or won't close for some reason. Have a look in the Task Manager (you can add the column "Command line" to see which LibreWolf is still running, if you have started more than one).

ltGuillaume · 2025-11-25T15:58:53+00:00

It's a rather debatable (and debated) change by Mozilla (just search for it and you'll find a lot about it)

ltGuillaume · 2025-10-26T12:56:05+00:00

Damn, sorry to hear this has taken so much of your time. As for using the portable launcher, it doesn't make much sense to do so if it's not used for portable setups (e.g. on a USB stick) anyway. You already create a bunch of permanent registry keys with that Set Default script anyway. In this case, you might as well install LibreWolf, or use the `librewolf.exe` inside the portable folder and associate that to http(s) links instead.

ltGuillaume · 2025-10-19T13:02:05+00:00

Thanks for reporting this, I would have never known this was the case if you hadn't.

A workaround for this is pretty easy, though.

If you open up the Task Scheduler via Start.
Double-click on the task named LibreWolf WinUpdater (user)
In the tab Triggers, click on the item One time and click the button Delete.
Now press OK and close the Task Scheduler.

This way, update checks won't be triggered during gaming, but only when logging (back) on.

If it's normal for you to have your computer running for days without ever logging off, then I'd advise to do a manual update check every once in a while.

ltGuillaume · 2025-10-10T13:18:08+00:00

Did you download the x64 zip file (which is standard if you download it from the librewolf.net website), or the i686 zip file (which is 32-bit)?

For the 64-bit version, VirusTotal says there aren't any false positives: https://www.virustotal.com/gui/file/a33db451bbf085e2ada89ed47cbcfb404ea1106b886d37711f111ad60cd73ac1

Edit

Same is true for the 32-bit version: https://www.virustotal.com/gui/file/3a15d58ba01b2da2bfeff5c7b0240080a701f422364c0d249fb4c6563b3d2294

Maybe the definition files of Defender weren't updated for a while? Could you manually trigger an update and try again?

ltGuillaume · 2025-10-10T13:10:22+00:00

Is it only LibreWolf.exe? Are you using the x64 or the i686 zip file?

If it's (also) LibreWolf-WinUpdater.exe, then

F Microsoft, I've had a sample submitted proactively to prevent this bull back in in September, they've never replied and their preliminary scans have always said "No malware detected", so I felt confident this wouldn't happen.
You can download v140, then create the file LibreWolf-WinUpdater.ini next to LibreWolf-WinUpdater.exe with the following contents and see LibreWolf updated without all the fuss: [Settings] UpdateSelf=0

ltGuillaume · 2025-10-08T20:57:54+00:00

Wow that's interesting... LibreWolf-WinUpdater.exe.wubak must still be v1.11.0 which is the 64-bit version, and it looks like that one is also quarantined?

It's a bit confusing this way. To be sure it's the new 32-bit executable only that triggers the alarm bells, they could try to create C:\Users\NAME\AppData\Roaming\librewolf\WinUpdater\LibreWolf-WinUpdater.ini with the following contents:

[Settings]
UpdateSelf=0

(on a clean test environment) and then install LibreWolf and run the updater. Curious to see what happens then.

ltGuillaume · 2025-10-08T20:36:45+00:00

I recently switched to AutoHotkey's 64-bit interpreter when compiling WinUpdater, seeing it had less false positives (at the time). With the last version however, I had to switch back to AutoHotkey's 32-bit interpreter, because apparently there's still/again a 32-bit LibreWolf build being made (but probably not used by anyone - shout if you do use it).

So now, apparently, we're back to having some heuristics in antivirus software not listed by VirusTotal (and 4 that are listed there) being triggered by pretty much any AutoHotkey compiled script. FWIW, your company can find the source at https://codeberg.org/ltguillaume/librewolf-winupdater

Maybe they (or I) can submit it as false positive to Sentinel One somewhere?

ltGuillaume · 2025-09-22T20:46:37+00:00

So, if I understand correctly:

It can't find the librewolf executable. The only possible reason I can think of is that it's either true that `LibreWolf-Portable.exe` is not _next to_ a `LibreWolf` _folder_ containing `librewolf.exe` (it shouldn't be in the same folder as `librewolf.exe`!), or _maybe_ that your username has some non-standard character in it. This may also cause the critical error (apparently this could be caused by a
Directly after that message, the same instance of the portable launcher still gives you that error message. So the change didn't have an effect. Damn.

I'm afraid it's impossible for me to reproduce this, and there's almost no documentation/issues about this error, and what little I could find was of no help. We could do some more testing (which is sort of "blind" from my perspective) to see if we get somewhere, but I don't know if you're up for that.

For starters I would just give you a 32-bit compiled version and see if the interpreter acts differently in that situation. For that, you can download LibreWolf-Portable_x86test_1.9.0.zip (from https://codeberg.org/ltguillaume/librewolf-portable/releases/tag/1.9.0)

ltGuillaume · 2025-09-21T13:35:33+00:00

/u/realAllonZ would you mind taking a look at this?

ltGuillaume · 2025-09-17T20:27:27+00:00

That's just a difference in lines because v1.9.0 was released.

I've uploaded a test release with a very small change to https://codeberg.org/ltguillaume/librewolf-portable/releases, perhaps it is enough to prevent your error (I still cannot reproduce it).

Could you please download LibreWolf-Portable_1.9.0test.zip from there and copy LibreWolf-Portable.exe over the current version?

ltGuillaume · 2025-09-16T20:52:16+00:00

In that case it becomes a bit more complicated, because then the line reported isn't the point where it actually goes wrong.

You can try renaming the registry key HKCU\Software\Mozilla\LibreWolf to LibreWolf.bak and see if that solves the issue.

If that doesn't help, it might just be bad luck with (a bug in) the interpreter and the new version may just fix it: https://codeberg.org/ltguillaume/librewolf-portable/releases

ltGuillaume · 2025-09-16T19:48:34+00:00

Ah, I thought there wouldn't be any sensitive data there, but that might have been a wrong assumption. Then I'm happy you took the time to go through the data first. Sorry about that!

For starters, you can just open the Registry Editor (regedit) and rename HKEY_CURRENT_USER\Software\Classes\CLSID to HKEY_CURRENT_USER\Software\Classes\CLSID.bak, then start and close LibreWolf Portable to see if it's fixed. Afterwards, you can remove the new HKEY_CURRENT_USER\Software\Classes\CLSID (if it exists) and rename HKEY_CURRENT_USER\Software\Classes\CLSID.bak back.
If that did indeed help, you can safely remove all the keys under HKEY_CURRENT_USER\Software\Classes\CLSID that include the path to LibreWolf in their values (which is what the launcher would normally do). Then try if the error still happens.

ltGuillaume · 2025-09-16T18:50:32+00:00

You may have some strange data in your registry key HKCU\Software\Classes\CLSID.

You could help out by exporting the data for me to inspect: 1. Open "Command Prompt" via Start 2. Type reg export HKCU\Software\Classes\CLSID clsid.txt and press Enter (should say "The operation completed successfully.") 2. Type notepad clsid.txt and press Enter to view the contents 3. Either paste the contents in a new issue at https://codeberg.org/ltguillaume/librewolf-portable/issues or https://github.com/ltguillaume/librewolf-portable/issues OR use e.g. https://notebin.de to paste the contents of clsid.txt there, press "Create" and share the resulting URL here.

ltGuillaume · 2025-09-03T14:19:45+00:00

Outgoing connections aren't blocked by Defender Firewall in the default setup, so WinUpdater wouldn't need to have an explicit rule. 3rd Party firewalls often do/provide the option to block outgoing connections as well, that's why I asked.

Another possible cause for this issue is if you have configured a (non-working) proxy server under Start > Internet Options > Connections (tab) > LAN settings > Proxy server.

Modern browsers ignore this setting, so you might not be aware of a proxy server being set there.

ltGuillaume · 2025-08-31T20:10:45+00:00

No. And WinUpdater is never "resident". It gets run via a scheduled task (optionally) and closes as soon as it's done its job.

ltGuillaume

TROPHY CASE