Losing your cookies

My browser lost its cookies” has long been one of the most longstanding Support complaints in the history of browsers. Unfortunately, the reason that it has been such a longstanding issue is that it’s not the result of a single problem, and if the problem is intermittent (as it often is), troubleshooting the root cause may be non-trivial.

In this post, I’ll explain:

  1. How cookies are stored,
  2. What might cause cookies to go missing, and
  3. How to troubleshoot missing cookies

Background: Session vs. Persistent

Before we get started, it’s important to distinguish between “Session” cookies and “Persistent” cookies. Session cookies are meant to go away when your browser session ends (e.g. you close the last window/tab) while Persistent cookies are meant to exist until you either manually remove them or a server-specified expiration date is reached.

In a default configuration, closing your browser is meant to discard all of your session cookies, unless you happen to have the browser’s “Continue where I left off” option set, in which case Session cookies are expected to live forever.

Chromium stores its persistent cookies as encrypted entries in a SQLite database file named Cookies, found within the profile folder:

Unfortunately, as a user it’s not trivial to understand whether a given cookie was marked Persistent and expected to survive browser shutdown. You have to look at either the 🔒 > Cookies > Cookies in use dialog:

…or the F12 Developer Tools’ Application tab:

If the cookie in question was set as a Persistent cookie, but it disappeared unexpectedly, there could be any of a number of root causes. Let’s take a look.

Culprit: User Settings

The most common causes of cookies going missing are not exactly a “bug” at all– the cookies are gone because the user either configured the browser to regularly clear cookies, or instructed it to do so on a one-time basis.

Microsoft Edge can be configured to clear selected data every time the browser is closed using the option at edge://settings/clearBrowsingDataOnClose:

This is a powerful feature useful for creating an “Ephemeral Profile“, but if you set this option on your main profile and forget you did so, it can be very frustrating. You can also use edge://settings/content/cookies to clear cookies on exit for specific sites:

That same page also contains an option to block all cookies in a 3rd party context, which can have surprising consequences if you set the option and forget it.

Culprit: User Actions

By hitting Ctrl+Shift+Delete or using the Clear browsing data button inside about://settings, you can clear either all of your cookies, or any cookie set within a particular date range:

Notably, the claim this will clear your data across all your synced devices does not apply to cookies. Because cookies are not synced/roamed, deleting them on one computer will not delete them on another.

You can also use the 🔒 > Cookies > Cookies in use dialog to remove cookies for just the currently loaded site, or use edge://settings/siteData to clear cookies for an individual site:

Culprit: Multiple Browsers/Profiles/Channels

For me personally, the #1 thing that causes me to “lose” cookies is the fact that I use 14 different browser profiles (8 in Edge, 4 in Chrome, 2 in Firefox) on a regular basis. Oftentimes when I find myself annoyed that my browser isn’t logged in, or otherwise is “missing” an expected cookie, the real reason is that I’m in a different browser/channel/profile than the last time I used the site in question. When I switch to the same browser+channel+profile I used last time, the site “magically” works as expected again.

Culprit: SQLLite DB Load failure

As mentioned above, Chromium-based browsers store persistent cookies in a SQLite database in the user’s Profile folder, encrypted using a key from the profile.

In Fall 2023, users of Microsoft Edge on Mac found that each time their browser restarted, all of their persistent cookies were lost. Not long after, some Edge users on Windows reported the same problem.

Both of these problems shared a similar cause, reached differently.

In both cases, the source of the error could be seen in the about:histograms page; users would see an entry named Cookie.LoadProblem with a value of 3 (COOKIE_LOAD_PROBLEM_OPEN_DB), and an entry named Microsoft.SQLite.Database.OpenFailure with a value of 14 (SQLITE_CANTOPEN).

In both cases, the team immediately began investigating what went wrong.

In the case of Mac, the problem was related to a race condition in the initialization of an experimental feature (the Edge VPN). This race condition caused an Edge process to attempt to open the Cookies database too early, before the Network Process’ sandbox had been granted access to the database’s location within the file system. The problem was quickly eliminated by disabling the experiment from the Experimental Configuration Service (ECS) server until the race condition could be corrected.

On Windows, the direct cause was that at the end of July 2023, Chromium landed a change that meant that if the browser could not open its cookie database exclusively (with no other processes having it open simultaneously), the browser would not load the database at all. This meant that if any other process had already opened the cookie database for any reason, the new Edge session would start with with an empty cookie jar, losing all of its persistent cookies.

An alert Windows user reported the cookie loss problem and collected a SysInternals’ Process Monitor log of filesystem activity on the cookie file. Unfortunately, he didn’t manage to catch any unexpected processes opening the file, but he then used SysInternals’ Handle and found that a process named UpdateBrowserForApp.exe had the cookie database open.

He performed his own sleuthing and found that this process seemed to be correlated with the Bing Wallpaper app, and some users had found that removing the app caused the Edge problem to disappear.

We talked to the owners of UpdateBrowserForApp.exe and found that the intent of this utility was to set a cookie that would allow a website to detect that the Wallpaper app was installed so that it could stop offering the app to users who’d already installed it. The Edge team explained that this was not a safe practice– beyond the immediate problems caused by exclusive locks, Chromium’s SQLite cookie database format is not a stable extensibility point, and the schema can change in any browser update. Therefore, using any external utility to modify the cookie database is completely unsupportable. The Wallpaper team released an update (v2.0.0.5) to turn off the bad behavior.

Reliably and safely communicating between Websites and Apps is a challenging problem space post-IE days; I explore this area in depth in my post about Web-to-App (and App-to-Web) Techniques.

Culprit: 3rd-Party Cleanup Utilities

Sometimes, a user loses their cookies unexpectedly because they’ve run (or their computer automatically ran) any of a number of 3rd-party Privacy/Security/Cleanup utilities that include as a feature deletion of browser cookies. Because these tools run outside of the browser context, they can delete the cookies without the browser’s awareness or control.

Culprit: Website Changes

Websites can change their behavior from minute to minute (especially when they perform “A/B testing” to try out new fixes. Sometimes, a website will, knowingly or unknowingly, cause a cookie to be discarded or ignored when new website code is rolled out. Websites can even cause all of their cookies to be deleted (e.g. when a user clicks “Logout”) using the ClearSiteData API.

(Unlikely) Culprit: Lost Decryption Key

As I mentioned earlier, Chromium encrypts cookies (and passwords) using an encryption key that is stored in the browser profile, and which is itself encrypted using a key stored by the OS user account.

If the key in the Chromium profile is deleted or corrupted, Chromium will not be able to obtain the AES key required to decrypt passwords and cookies and will behave as if those data stores were empty.

Similarly, the same loss is possible if the OS user account’s encryption key is lost or reset. This should be very rare, but prior to Windows 10 20H2 there was a bug where the key could be lost if the S4U task scheduler was in use. In 2022, a similar bug hit PCs with 3rd-party credential providers installed. Finally, if the user’s password is forgotten and “Reset”, the account’s encryption key is intentionally reinitialized, resulting in the “irreversible loss of information” mentioned at the top of the confirmation dialog box:

(Unlikely) Culprit: Data Corruption

Chromium has made significant technical investments in protecting the integrity of data and I’m not aware of any significant issues where cookie data was lost due to browser crashes or the like.

Having said that, the browser is ultimately at the mercy of the integrity of the data it reads off disk. If that data is corrupted due to e.g. disk or memory failure, cookie data can be irretrievably lost, and the problem can recur until the failing hardware is replaced.

Troubleshooting Steps

  1. Check which browser/channel/profile you’re using and ensure that its the one you used last time.
  2. Visit about://settings/clearBrowsingDataOnClose to ensure that you’re not configured to delete cookies on exit.
  3. Visit about://settings/siteData to see whether all cookies were lost, or just some went missing.
  4. Visit about://settings/content/cookies to see whether third-party cookies are allowed, and whether you have any rules to clear a site’s cookies on exit.
  5. If cookies are missing after restart, visit about:histograms and look for an entry named Cookie.LoadProblem with a value of 3 (COOKIE_LOAD_PROBLEM_OPEN_DB), or an entry named Microsoft.SQLite.Database.OpenFailure with a value of 14 (SQLITE_CANTOPEN)
  6. If you use the browser’s Password Manager, see whether your saved passwords went missing too, by visiting about://settings/passwords.

    If they also went missing, you may have a problem with Local Data Encryption keys. Check whether any error values appear inside the about:histograms/OSCrypt page immediately after noticing missing data.
  7. Visit Cookie/Storage test page, pick a color from the dropdown, and restart your browser fully. See whether the persistentCookie and localStorage values reflect the color previously chosen.
  8. Use the Windows Memory Diagnostic in your Start Menu to check for any memory errors.
  9. Use the Properties > Tools > Check for Errors option to check the system drive (usually C:) for corruption:

-Eric

Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ Microsoft 2001-2012, and 2018-, working on Office, IE, and Edge. Now a GPM for Microsoft Defender. My words are my own, I do not speak for any other entity.

Leave a comment