FirefoxPortable.exe burden HDD only after reload Firefox.
If you close Firefox and restart, then it's okay.
http://ipic.su/img/img7/fs/kiss_4kb.1467032652.png
So in fact there shouldn't be !? 
Fix please!
(Win7x32 , Firefox 47)
You are here
[Fixed] FirefoxPortable.exe higher disk access in recent builds
June 27, 2016 - 9:09am
#1
[Fixed] FirefoxPortable.exe higher disk access in recent builds
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
FirefoxPortable.exe only accesses the disk before and after running firefox.exe. It does this to adjust paths in the profile and then clean a couple things up after exit. It does nothing at all disk-wise while Firefox is running. Literally nothing disk-wise.
You can look at the code yourself. It just sits there and waits for Firefox to close.
Sometimes, the impossible can become possible, if you're awesome!
Why so soon be expressed "Incorrect" ?!
The problem exists, and here's the proof :
I check the version: 46,45,44,43 - burden HDD :evil:
Version 42 - OK !
I replaced the FirefoxPortable.exe 42 >>> 47 - OK !
i.e., as i understand it, this has something to do with the choice of the bitness.
Fix please !
I can't reproduce this on 64-bit or 32-bit Windows. After Firefox is up and running, FirefoxPortable.exe sits there doing nothing with 0 I/O Reads/Writes/Other and 0 I/O Read/Write/Other Bytes, just as always. The only change in the 43.0 launcher was to detect whether the OS was running 64-bit before launch and then launch the correct version of Firefox. The code while running is the exact same 6 lines as it's been for years.
For completeness, do you have any custom settings in FirefoxPortable.ini? What app are you using to map the the disk use? Are you running any extensions that could cause Firefox to restart itself?
The only thing I can think of is if you somehow triggered something that would escape the ExecWait (firefox.exe restarting itself) and cause it to fall back to firefox.exe check for running every 2 seconds. But there's nothing I can think of that would work one way with the pre-64-bit launcher and one way post.
Sometimes, the impossible can become possible, if you're awesome!
FirefoxPortable.exe burden HDD only after reload Firefox.
(I downloaded the clear builds and immediately checked them)
Please answer the questions in the above post.
Additionally, it's almost no burden if it needs to do the fallback check every 2 seconds. It's a single load of a single 4K DLL from the local hard drive's TEMP directory. And it's almost definitely cached in memory.
Sometimes, the impossible can become possible, if you're awesome!
I downloaded a clean build, install any addon require a reboot and rebooted.
Please note that when I replace FirefoxPortable.exe of version 42, the disk accesses are not observed.
Once again, please answer ALL the above questions before posting again.
Sometimes, the impossible can become possible, if you're awesome!
I do not understand what it is. Nothing to use.
The screenshot you showed above. What is it from? I wanted to reproduce it exactly. Though I'll need to somehow trigger a firefox.exe restart as that should normally not happen.
And, PLEASE, again, answer all the above questions.
Sometimes, the impossible can become possible, if you're awesome!
Yes, then I guess what you mean.. Process Hacker v2.39
Here's another http://ipic.su/img/img7/fs/kiss_5kb.1467129458.png
On other issues, I have already given the answer :
" I downloaded a clean build, install any addon require a reboot and rebooted. "
Ah ok, that helps. In Task Manager, it made almost no difference between them. In Process Hacker, it shows a clearer difference.
It seems that the FindProcDLL included in NSIS Portable 2.46 Rev 2 is different compared to the one in the NSIS Portable 2.46 Rev 3 release. That's what changed between Firefox 42 and Firefox 43. Nothing in our code changed, which is what made this make no sense. I believe the newer one works with 64-bit processes while the older does not. I'm investigating further.
Sometimes, the impossible can become possible, if you're awesome!
Ok, it seems that the newer version of the FindProcDLL plugin has a higher cost to doing a process check in terms of disk use. We can't revert to the old version used in NSIS 2.46 Rev 2 because that one only works with 32-bit processes and won't work with dual mode apps like Firefox Portable on 64-bit machines (the majority of users). But, this new FindProcDLL plugin does introduce a new method allowing for a low cost wait for a process to finish that won't consume CPU or disk. So, I've updated the Firefox Portable launcher to make use of that. Each time firefox.exe restarts there will be a single check on the process and then a wait, so you won't see the spike every 2 seconds. firefox.exe restarts rarely so this will reduce the overall cost of the launcher in terms of CPU and disk compared to the old one.
This change is included in Firefox Portable 47.0.1 which is building now.
Sometimes, the impossible can become possible, if you're awesome!
Thank you !
Let's hope for the best.
And I have already implemented auto-kill FP.exe after starting Firefox
(My Firefox is on a stationary PC, just like when everything in the same folder on the D:)
Don't auto-kill FirefoxPortable.exe - this is what manages the portability. Just wait for the update to be pushed out.
This is fixed in Firefox Portable 47.0.1 posted today. The new launcher will filter out to ESR, Beta, and Dev as they are released as well. You can replace any of their launchers with this one if you'd like the benefit today. This only affects slightly higher disk access after firefox.exe is restarted (not an everyday thing).
I'll be adding this same setup to the Thunderbird launcher and PAL itself in later releases.
UPDATE: Fixed in Thunderbird Portable 45.2.0
Sometimes, the impossible can become possible, if you're awesome!