Unknown SQLite db file ?

[inoperable]

I fished this during a debug session

winget (doesn't) in normal operation leave it in defaultState directory but deletes instantly running a command - so you wont notice since it lands in paging land normally.

file is named "{090B3813-6FFB-4592-BAD3-E2F658C3F4A9}" - appears to be some (random?) uuid.
its a sqlite database with some odd content

What is this file used for in winget?
Where can one find any information what those entries represent?

update: only place I cross-referenced it with is microsoft/winget-cli/src/AppInstallerSharedLib/SQLiteStorageBase.cpp

[inoperable]

I stand corrected, I found few references in https://github.com/microsoft/winget-cli/src/AppInstallerSharedLib/SQLiteStorageBase.cpp to ImmutableRead Database after gawking at the logs again.

Is there any documentation about the AppInstallerSharedLib parts?
I looked at https://learn.microsoft.com/en-us/windows/msix/manage/shared-package-container and
some other websearch results but those are MSIX / AppInstaller generics

[florelis]

If you want to dig deeper, you can run your winget command with --verbose to get logs that detail all the SQL operations. It will be a lot but you can get more info from there.

Off the top of my head I don't know for sure what that one database is or exactly what it contains, but in general we use SQLite databases to store and query information about installed and available packages. For example, when you update the winget source what you're getting is really a source.db database file.

We also create a (local, transient) database of all applications you have installed on your machine (from reading the ARP data in the registry) and use that to correlate with packages in the sources. So, for example, we create a table with the product codes of everything installed on your machine, and when you ask to install a package we query that table with the product code in the package's manifest to know if the application is installed. I'm guessing this is the db you're looking at.

All the tables in that screenshot you shared are for correlating installed apps with winget packages. For example, pfns are MSIX's Package Family Names, upgradecodes are MSI's Upgrade Codes, commands are the executables that a package provides, etc.

I don't think there is any real documentation about either AppInstallerSharedLib or the databases, as those are implementation details.

[inoperable]

The commands2 table is the list of commands that packages support and is used in conjunction with command2_map to create the many-to-many mapping between commands2 and packages

Thank you for clarifying this part - makes more sense now, I'm still don't know how the data is build or correlated:

If this represents relations of (all? recently updated? most popular?) commands/packages in the global repository- there is lot of stuff you don't want your package manager to install, and just going the list through there seem to be a lot of those. I can't really compare since scoop main repositories are cleaned up and secure, custom urls on the other hand is a whole different story. Its the nature of package managers that's you have a constant balance act between security and convenience - but looking at the data in the db it look like there is a lot of dubious stuff there (or it might be the nature of my userspace stuff, i dont understand yet how that file is build and based on what)

[inoperable]

I believe all of that is data from the manifests of available packages. You can go over to microsoft/winget-pkgs and search for them. You should be able to see each of them listed as a command in some package manifest. Same for the tags, product codes, etc.

OK, I need to dig in here into this part- and reinstate my assumptions ;>
Thank you for your time and I really appreciate your help here

[inoperable]

2025-04-18 16:03:42.643 [REPO] Opening database for ImmutableRead at 'C:
\Users\Admin\AppData\Local\Temp\WinGet\defaultState\{094D969B-CDCA-4E62-8178-52BE14D00A8E}'
2025-04-18 22:03:42.644 [REPO] Opened SQLite Index with version [2.0], last write [2025-04-13 07:11:07.000]

So, above that's the file that makes the disappearance act
And there is this line:

2025-04-18 22:03:42.668 [REPO] Creating new SQLite Index with version [Latest] at ':memory:'

Why would winget still need to pull data from and push data to "msstore" if I don't use it, and its removed from my config?

2025-04-18 16:03:42.666 [CORE] Adding chain to pinning configuration [Microsoft Store Source]:
DigiCert Global Root G3 : PublicKey
  Microsoft Azure ECC TLS Issuing CA 04 : Subject | Issuer
    sfdataservice.microsoft.com : Subject | Issuer
2025-04-18 16:03:42.666 [CORE] Adding chain to pinning configuration [Microsoft Store Source]:
DigiCert Global Root G3 : PublicKey
  Microsoft Azure ECC TLS Issuing CA 04 : Subject | Issuer
    sfdataservice.microsoft.com : Subject | Issuer
2025-04-18 16:03:42.666 [REPO] Source named 'msstore' is already defined at origin User. The source from origin Default is dropped.

Is this mapped db (which is basically a full inventory of all the packages installed locally, right?) is that winget sends to ms backend infrastructure for processing?

[Trenly]

Winget is not querying or pushing data to msstore in those log statements. In order to communicate with the Microsoft Store, WinGet has two built in certificates. These are considered the "pinned certificates" to ensure that communications received from the Microsoft Store are authentic. These certificates are always added to the certificate chain WinGet uses regardless of if there is any communication with the store or not. The first two log messages you’re seeing are just the loading of those certificates. The third line is just saying that because you removed the source (and it is a default source), it won’t be loaded.

---

Is this mapped db (which is basically a full inventory of all the packages installed locally, right?) is that winget sends to ms backend infrastructure for processing?

I'm not sure I fully understand your question, but I believe the answer is "no".

The database is exactly as @florelis described it - a compilation of all the data from the winget-pkgs repository.

When changes are made to the manifest yaml files over at winget-pkgs, they go through the PR validation process and get merged. After each merge, there is a continuous deployment pipeline that creates the PreIndexedPackage and uploads it to the CDN as the winget source. This Pre-indexed package is, effectively, an MSIX file that contains the sqlite database you're seeing.

When you run winget source update, WinGet will reach out to the CDN, download the latest MSIX package, and install it. This results in the sqlite database on your machine being updated.

---

Outside of the database being updated on your machine, it seems like you want to know why it is there and how it is used.

Imagine a scenario where you have only one application on your computer. How does WinGet know what that application is? Well, every application has a name that it displays in the registry, so you can ask a hypothetical endpoint if it has any knowledge of the Name. But wait, that isn’t the only identifier, because two applications can have the same bame but different publishers, so now you need a second request to narrow the search window to just applications by name and publisher. But wait, you also have a product code you can use, except the hypothetical endpoint may or may not know about the product code, so now you need another request to see if it knows about the product code. And so on and so forth. Now expand that to 100+ applications and millions of users, and it becomes apparent that having a service search through the text of manifest files isn't going to work.

So, instead, the publishing pipeline creates this database of all the applications that WinGet knows about. The database includes the bames of the packages, the product codes of the packages, the publishers, product family names (pfns), and upgrade codes. This is exactly what the winget source is, and is exactly the database you’re seeing.

This way, when you run a command like winget upgrade, the CLI can look at the names, publishers, product codes, etc, of all the software that you have installed on your system, and see if it is a package that WinGet knows about without having to send a ton of data across your network every single time.

And then, lets say that you want to check if WinGet has a package available that you may want to install - how would you find that package? You can search by name, but maybe you are looking for options instead of a specific package - lets say you know you want one related to decryption; Well, when users submit their software to the WinGet source they can add tags, but now you'd have to go check all of those manifests for the tags . . . Unless they get built into the database you already have. Same thing with commands - you know you want to install a program for running grep but don’t know what ones WinGet knows about - winget search --command grep is what you would run, but then information about what commands map to which packages has to be in that database.

Tip

The database is just a way for WinGet to check what packages are available in the winget-pkgs repository

---

So, the database doesn't indicate anything about what is actually on your machine. Nothing about the actual packages on your machine is "sent to infrastructure for processing". In fact - it's the exact opposite.

The database is sent down from MSFT ifrastructure to your machine as a full inventory of all the packages that WinGet could manage, install, upgrade, etc. Then, all the processing happens locally.

---

If this represents relations of (all? recently updated? most popular?) commands/packages in the global repository- there is lot of stuff you don't want your package manager to install, and just going the list through there seem to be a lot of those.

Yes, this database represents the relations of all the items in the global repository. Not every user will want every package, and everyone has different ideas about what should be manageable through the package manager.

Its the nature of package managers that's you have a constant balance act between security and convenience - but looking at the data in the db it look like there is a lot of dubious stuff there

All packages in the global repository go through rigorous scanning before they are allowed in. Some details are in the FAQ. Each and every installer goes through both static and dynamic analysis, with multiple scans being perfomed throughout the process. The validation pipelines download, install, and run each package checking it for malware, PUA, and ensuring that nothing nefarious is happening through the entire process. One example I can give of how rigorous the scans are is this pr, where the application is not malware in any means, the code does nothing nefarious, and is trusted by many users. However, one of the third party libraries they brought in was signed with a certificate that was later compromised and used to sign malware. During the validation process, the scans saw that the library was signed with that certificate and - even though the library is bot malicious - flagged the entire process simply due to the fact that the certificate that signed the library was known to be associated with malware that was built after the library was.

So yes, it is a constant balancing act, but I believe @denelon and the team have done a great job of ensuring that all the packages in the community repository are exactly what they purport to be

[inoperable]

This clears a lot of wrong assumptions, thank you for the extensive answer.

Finding information is quite difficult, ms is a gigantic organization and the docs are wide and wildly spread across all different platforms/projects - nothing you can do about that, but that's
my excuse to post my pesky questions (and steal your time). I really appreciate the time you put into this, since it clears a lot of data anxiety and reinstate a lot of previous assumptions 👍

[inoperable]

However, one of the third party libraries they brought in was signed with a certificate that was later compromised and used to sign malware. During the validation process, the scans saw that the library was signed with that certificate and - even though the library is bot malicious - flagged the entire process simply due to the fact that the certificate that signed the library was known to be associated with malware that was built after the library was.

That's a good thing- and I wouldn't make it any different.

The certificates are currently a major hurdle to work with, i recently read there are changes coming in next 4 years that will shorten certs lifespans radically, however this is a bet on automation and i couldn't find anything about the shaky pyramid of authority that it stands on.
Personally I would love to have the ability choose certificate necessities in the os and the ability to disable all of it - if the user chooses too, there are few things less enjoyable then self-signing software produced on owned hardware just to test it (distribution is a whole different thing, and that where its necessary, but in my own garage i dont want to think about certificates - my choice, my problem)