Regarding "Profiles.ini" and enigmatic "InstallXXX" sections

User Help for Mozilla Thunderbird

User avatar
Posts: 4
Joined: November 1st, 2019, 5:37 am

Post Posted November 1st, 2019, 5:48 am


I hope this is the right place to ask.

Recently I noticed that Thunderbird (and Firefox likewise) now creates mysterious sections called "InstallXXX..." (for example: "Install8216C80C92C4E828") in its profiles.ini file :shock:

Furthermore, it seems that the "Default=1" entry in the normal "ProfileXXX" sections (e.g. "Profile0") seems to be ignored now.

Instead, as it appears to me, now the path stored in the entry "Default" in one of the mysterious sections called "InstallXXX..." is used by Thunderbird (or Firefox) to figure out what is the default profile to be used.

From what I have found so far, the cryptic number in "InstallXXX..." is some sort of application ID.

It is the same on different machines that I checked, so it's a fixed value (not randomly generated per machine). But it seems to differ between Thunderbird and Firefox. And also between 32-Bit and 64-Bit versions of those.

My question: Are my finding correct, so far? And, even more important, where are those numbers (application IDs) defined? Is there an exhaustive list of all existing IDs somewhere? :?:

Thank you and best regards.

PS: I scanned the complete Thunderbird source code package, which is quite immense, but couldn't find the string "8216C80C92C4E828" to be defined anywhere. Also couldn't find it in my "Thunerbird.exe" binary :?

(But then again, I don't really know what I am looking for. Maybe it's defined in a different format or base and so I didn't find it)
Last edited by lordmulder on November 1st, 2019, 7:57 am, edited 1 time in total.


User avatar
Posts: 46225
Joined: July 30th, 2003, 5:06 pm

Post Posted November 1st, 2019, 6:04 am

I believe the changes you are talking about are due to a new version of the Mozilla toolkit library (used by both Firefox and Thunderbird) wanting a separate profile for release builds, a separate profile for beta builds etc. The giveaway is the Locked=1 entry in the section. If you installed Thunderbird 68.* in a different location that made it create a new profile (rather than reuse the existing one) due to that feature.

You see a mix of old and new syntax in profiles.ini due to backwards compatibility.


User avatar
Posts: 4
Joined: November 1st, 2019, 5:37 am

Post Posted November 1st, 2019, 6:11 am

Thanks for your reply!

Especially I see that Thunderbird does not default to the profile that has "Default=1" in its "ProfileXXX" section, but instead to the profile whose path is set in the "Default" entry of the mysterious "InstallXXX" section.

But, because there can be multiple "InstallXXX" sections, with different application IDs, I need to know the specific application ID that I am looking for, I suppose.

So, again my question: Where are those numbers (application IDs) defined? How does a specific Thunderbird build know which "InstallXXX" section it has to use? Is there an exhaustive list of all existing IDs available somewhere?

(I searched, but couldn't find anything around the net)

Any help would be much appreciated.
Thank you!
Last edited by lordmulder on November 1st, 2019, 7:58 am, edited 2 times in total.

Posts: 578
Joined: January 30th, 2019, 9:38 am

Post Posted November 1st, 2019, 6:44 am

In my opinion, these numbers are generated although not randomly generated - you will not find a list of them anywhere. Generated from some aspect of the computer hardware or file path or both, then hashed.
If you have a need for multiple profiles, it might be easiest to backup everything and go back to Thunderbird 60, and build up everything clean after renaming profiles.ini installs.ini and compatibility.ini if they exist. 60 does not use these features or hashes and does not create extra profiles automatically.


User avatar
Posts: 4
Joined: November 1st, 2019, 5:37 am

Post Posted November 1st, 2019, 8:25 am

kerft, thanks for the input.

After some more research and looking at the Thunderbird source code, I figured out that those mysterious numbers are actually computed from the application's install path.

This explains why the number was the same on different machines for the same application, as long as the application was installed to the default directory on each machine (e.g. "C:\Program Files\Mozilla Thunderbird").

But, as soon as I install to a different non-standard directory (e.g. "C:\TBird"), the number in my profiles.ini comes out very different :idea:

As far as I can tell, the relevant function is nsXREDirProvider::GetInstallHash() which detects the directory where the executable is located, performs some normalization on that path and finally calls HashInstallPath().

HashInstallPath() in turn calls ::GetInstallHash() with the given path and an additional "vendor" argument. The actual computation happens in the ::GetInstallHash() function:

(Note that parameter "vendor" is not used at all. Also "useCompatibilityMode" defaults to false, and HashInstallPath() doesn't explicitly set it)

Code: Select all
nsresult GetInstallHash(const char16_t* installPath, const char* vendor, mozilla::UniquePtr<NS_tchar[]>& result, bool useCompatibilityMode) {
  /* ... */
  // Unable to get the cached hash, so compute it.
  size_t pathSize =
      std::char_traits<char16_t>::length(installPath) * sizeof(*installPath);
  uint64_t hash =
      CityHash64(reinterpret_cast<const char*>(installPath), pathSize);
  size_t hashStrSize = sizeof(hash) * 2 + 1;  // 2 hex digits per byte + null
  result = mozilla::MakeUnique<NS_tchar[]>(hashStrSize);
  int charsWritten;
  if (useCompatibilityMode) {

     /* ... */

  } else {
    charsWritten =
        NS_tsnprintf(result.get(), hashStrSize, NS_T("%") NS_T(PRIX64), hash);
  if (charsWritten < 1 || static_cast<size_t>(charsWritten) > hashStrSize - 1) {
    return NS_ERROR_FAILURE;
  return NS_OK;

So, after all, the mysterious numbers in those "InstallXXX" sections of the profiles.ini just are the CityHash64 of the install path :!:


User avatar
Posts: 4
Joined: November 1st, 2019, 5:37 am

Post Posted November 4th, 2019, 12:41 pm

After spending 2 days trying to figure out how to compute the same "InstallHash" from the install path as Thunderbird does, here is some important information:

  • The install path must be converted to UTF-16 format, then the UTF-16 string must be re-interpreted as bytes-array (i.e. two bytes per character), before passing it into the CityHash64() function. Note that the "length" value passed to CityHash64() has to be twice the length of the path string, because CityHash64() specifies the size in bytes, but UTF-16 uses two bytes per character. Also, the path must not contain the EXE file name or a trailing backslash!
  • Thunderbird apparently does not use the "official" CityHash64() code that you can find in Google's source repository on GitHub. Instead, it seems to use a "custom" variant of CityHash64() that produces very different result from Google's official code. I have no clue why that is. It probably is a form of "security by obscurity". I also tried several other CityHash implementations (e.g in Python), but none of them matched Mozilla's output; they all matched Google's output though.

Conclusion: You have to use the Mozilla-specific variant of CityHash64 (city.cpp), which can be found at "other-licenses/nsis/Contrib/CityHash/cityhash/city.cpp" in the Thunderbird (comm-central) repository, in order to compute the correct hash value :shock:

Return to Thunderbird Support

Who is online

Users browsing this forum: Bruce L. and 5 guests