Have to report the following issue: I try to update to the newest version of FFx by manually starting the platform updater from the platform menu. The new version of the FFx was found, downloaded and kinda successfully installed. After the start of the FFx I got the message, that xul.dll isn't compatible with the current version.
I checked this manually, and the xul.dll really looks like to be from the previous version. So I downloaded the new portable version of the FFx manually and started the update manually. This time I got an error, that the xul.dll couldn't be overwritten. All the repeats of this operation couldn't overwrite the file. So I have to go further by pressing the ignore button. The result was the same - FFx files were mixed and the program couldn't be started.
With a little help of the Process Explorer, the xul.dll handle was found and fried. After that, it was possible to completely install a new portable version. So the issue here is probably that platform updater updates everything in the "ignore all the errors" mode. Then installation always succeed, but the result isn't always can be run. Are there any ways to correct this?
Maybe this isn't a FFx installer issue, but a common issue of the portable installers and platform?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I personally need to make several tests before to report a bug.
For example: I have some issues with some apps on my main computer, so I need to make: tests on other computers (32/64 bit, different OS), fresh platform installs, and even trying older versions or uninstalling related apps (after making backups).. Few logical ways to locate the bug!
“My brain is only a receiver, in the Universe there is a core from which we obtain knowledge, strength and inspiration. I have not penetrated into the secrets of this core, but I know that it exists.”
― Nikola Tesla ―
Were there any errors as the installer was running? Was there anything on your system locking the files? This happens occasionally specifically with XUL.dll for some reason and I'm unsure why. If an error isn't thrown, I'm wondering if there is an NSIS bug not detecting the issue as it occurs. It should throw a retry, ignore, abort error when it can't write to a file specifically.
Note: This isn't platform related, it's installer related.
Sometimes, the impossible can become possible, if you're awesome!
I think, we have here some kind of misunderstanding, so I repeat the whole situation in smaller manner. Start platform application updater from platform menu → it finds a new version of FFx → let it install, updater reports everything is OK → start FFx, have an error, because xul.dll is wrong → manually download the FFx portable installer → this one gives us an error, because xul.dll is locked → unlock it with Process Explorer → now everything is fine.
So the trouble here is a different behavior of the installer started from platform updater and started manually. Last one gives user an error, which is correct, and now one knows it and can deal with it. The first one just ignores an error and left the user with a mixed installation of FFx, which can't run.
Turns out when NSIS is running in silent mode, it defaults to "Ignore" when encountering a locked file. The only other option is setting it to default to "Abort", which will result in a half-installed Firefox Portable that will still be broken as it is with xul.dll. This may, however, at least pass an error code back to the updater/app store. I'm going to look into this.
In the meantime, we need to figure out why your xul.dll keeps getting locked. Do you have anything else accessing it? Any sort of 'web protection' software that could mess it up?
Sometimes, the impossible can become possible, if you're awesome!
I think we have some non-technical, philosophic questions. What is better: to report an error or not? In both cases the installation is broken, but at least the user is notified, that something went wrong. So here I think that the message would be a better solution.
But what would be the user's reaction? Should he try to download the application installer and manually update it? This breaks the whole idea behind the platform menu and updater.
On the other hand, this is a clear example of needed transaction management - we need to make a backup copy of the application folder, so in case of trouble we have a state to roll back to. And this could be a complex thing to do.
All of the above wouldn't probably directly work because the xul.dll is locked till the next restart or some different way to unlock it.
As of the "what have locked it" question: as quite as I can remember (thanks God it doesn't happen really often) the handle was from the system directly. This is what Process Explorer shows you. So I can't tell which application caused this, not directly. It could be possibly only OS itself or AV - there are no other applications running at the update time.
The choice of options you're trying to decide between are not ones available, unfortunately. Based on looking into the way NSIS works in silent mode, the choice is to either (1) have it work as it does now and Firefox alert you with what's wrong the next time you run it or (2) have the Firefox Portable installer fail with a generic error message and no indication of what the locked file is. There does not appear to be a way to determine what the file is it can't write. With the first, we know what's wrong and the user has a path to fixing it. With the second, we have nothing to lead us in the right direction.
The workaround I can think of is to have the installer fail with a generic error passed back to the updater/app store and then have the updater/app store re-run it in non-silent mode which will give that Abort Retry Cancel message with the file that can't be written to. This will require altering the PA.c Installer and Updater/App Store. This will likely be changed in a future update. I've added it to the known issues but it is not a high priority as it's currently only affecting a single user.
We will not be doing transaction management or backups before upgrades. That will slow down and over-complicate the process for all users for just a handful of edge cases. In our current usage, you're the only user reporting this issue. NSIS itself doesn't handle this sort of thing as is one of the most popular Windows installers. If you'd like this functionality added to NSIS, you'd need to code it yourself or pay a developer to do so.
I'm not sure why the xul.dll is currently getting locked for you and no other users at present. I don't have any additional suggestions at the moment to help determine why either.
EDIT: I'm looking into checking for errors specifically and passing them up the line to the app store/updater.
Sometimes, the impossible can become possible, if you're awesome!
I know, that the alternatives I am talking about, are not here directly. But I think the compromise you are suggesting is a superb one. I only hope, that this wouldn't be so much confusion for a "normal" user, the case when silent update fails and the non-silent variant is started. Maybe, after small message with possible question, if one likes this semi-manual try or not. Usually, I try to imagine the reaction of somebody from this broad community of the non-technical users.
You and I would probably find a solution anyway, if there is any solution available.
What about the question "who is locking, who is having a handle on this DLL": I don't know either, and even if Process Explorer shows you no more information than that - I don't know any other way and source of information. Lucy enough, this happens really seldom, but the next time I could take a closer look at it. Even if I don't know how.
There are other apps that tell you exactly what is locking the file in most cases. Which of those apps to use though is a matter of choice.
The one I'm currently trying is a part of Microsoft Powertoys Preview (File Locksmith)
Thank you for the tip. Where I can find a portable version of this app?
As far as I know, a portable version of File Locksmith doesn't exist.
However, there is an alternative app already packaged here on PortableApps.com
https://portableapps.com/apps/utilities/iobit-unlocker-portable
Before File Locksmith, that one was what I was using myself (though installed non-portably)
Thank you for another tip - I'll try this one next time I'm in such trouble!
It's a bit more complicated as I'm trying to preserve the installer process and only show errors at the end. I can't do that with relaunching the installer in non-silent mode. Maybe I'll add an advanced setting for it or something, we'll see. Either way, it won't be coming for a bit.
Sometimes, the impossible can become possible, if you're awesome!
Thank you for your effort, sir!
Anyway, I hope, that with some time and energy investment, the better solution would see the light of the day.