Hi,

This issue seems related to how Firefox internally maps profile directories to profile configurations stored in `profiles.ini` and `installs.ini`. Firefox uses unique profile IDs and relative paths to maintain the integrity of each user’s environment, and renaming or altering these paths manually can lead to inconsistencies between the filesystem and the configuration references — especially if any cache or lock files persist.

Here are a few points that may help:

1. **Supported Approach:**

  Firefox doesn’t officially support renaming or “standardizing” existing profile folder names directly. The supported approach is to create a new profile using the `firefox.exe -CreateProfile` command, specifying the desired folder name (e.g. `firefox.default-esr`), then copying essential data files from the old profile into the new one. This ensures all internal mappings remain consistent.

2. **Critical Profile Files:**

  These are the minimum essential files for Firefox to launch and function correctly:

  * `prefs.js` — user preferences and settings.
  * `places.sqlite` — bookmarks and history.
  * `logins.json` and `key4.db` — saved passwords.
  * `cert9.db` — certificate database.
  * `handlers.json`, `formhistory.sqlite`, `cookies.sqlite`, and `permissions.sqlite` — additional browser data.

  Corruption or mismatch in these files can cause startup or UI issues.

3. **Possible Root Cause:**

  When you rename the profile directory and update the `.ini` files, some absolute or relative paths stored in files like `prefs.js` or internal cache data (e.g., `startupCache`, `xulstore.json`, or `parent.lock`) may still reference the old profile path. This can cause Firefox to hang or display a non-functional UI.
  Deleting `startupCache` and `xulstore.json` (and letting Firefox rebuild them) can often fix the “frozen UI” issue without a full reset.

4. **Recommendations:**

  * Test removing `xulstore.json`, `startupCache`, and `.parentlock` from affected profiles before a full wipe.
  * Consider automating a clean rebuild of these files post-migration.
  * Validate that the `Path` and `Default=1` entries in `profiles.ini` match exactly after renaming.

5. **Future-Proof Option:**

  If standardization is required mainly for management or backup purposes, you might use symbolic links or folder redirection rather than renaming existing profile folders. This keeps Firefox’s internal references intact while achieving consistent paths for your tools.

Can you check the javascript console to see if there are any errors?

You also might look at the command line parameters.

https://wiki.mozilla.org/Firefox/CommandLineOptions#User_profile

You could create a profile and just start Firefox with that profile and avoid the profiles.ini completely.

Thank you both for your responses.

We tested to remove xulstore.json, StartupCache (which did not exist for us) and parent.lock, but it did not fix our corrupted Firefox installs.

But based on the proposed solution we wrote a script which reverts the renamed profile folder in %appdata% based on the last used folder in %localappdata% (+ revert the changes in Profiles.ini and Installs.ini).

This fixed the corrupted firefox profile and by creating a junction with the "standardized name" that we need for our profile-management we got it working.

We are now trying to automatically repair corrupted profiles in the field and therefore two more questions came up:

- Is there a reliable way to tell if a firefox profile is working properly for the user? Based on the profiles we checked it seems as if there is e.g. a "activity-stream.contile.json" or "activity-stream.inferred_personalization_feed.json" in the %localappdata% profile folder that was last used, firefox seems to work.

- Is it safe to say that as long as installs.ini and profiles.ini are setup with a default user, that firefox will never create a new profile folder? Because if otherwise, we would have to keep our junction up to date as well...?

PS. on a corrupted firefox profile, we cannot open javascript console. The application is completely unresponsive and needs to be closed via taskbar or task manager.