# covdbg 1.4.0: shared library coverage and sign-in for one team

- Published: 2026-10-08
- Author: Rene Windegger
- Canonical: https://covdbg.com/announcing-covdbg-1-4-0/

---

**covdbg 1.4.0 is available.** It measures code that lives in shared libraries, the DLLs your tests link against or load at run time, and it makes signing in clearer: a sign-in is now for one team, and covdbg tells you which.

**In this release:** [Shared library coverage](#measure-the-dlls-your-tests-load) · [Sign in for one team](#sign-in-for-one-team) · [Upgrading](#moving-to-140)

## Measure the DLLs your tests load

Until now covdbg measured the executable it launched, and nothing else. A lot of Windows code does not live there: the library your unit tests link against, a plugin loaded with `LoadLibrary`, a Python extension module. That code ran during your tests, but it never showed up in the report.

In 1.4.0 you select the libraries to measure under `modules` in `.covdbg.yaml`, with the same patterns you already use for `files`:

```yaml
coverage:
  default:
    files:
      include:
        - "src/**/*.cpp"
    modules:
      include:
        - "mylib*.dll"                # By file name, in any directory
        - "build/**/plugins/*.dll"    # By path, relative to the config file
      exclude:
        - "mylib-thirdparty.dll"
```

covdbg instruments a selected library as soon as Windows maps it, before any of its code runs, including `DllMain`. That works for DLLs the executable imports and for DLLs loaded later with `LoadLibrary`. A library that is unloaded before the process exits keeps the coverage it collected, and each library is written to the coverage database as a module of its own, next to the executable.

A few details worth knowing:

- **Libraries are opt-in.** Without `modules.include`, covdbg measures only the executable, exactly as before.
- **`files` still decides what is measured.** A selected library contributes only functions whose source files pass your `files` patterns, so include its sources too.
- **Test hosts work.** When the executable has nothing of its own to measure, such as a test host or `python.exe`, covdbg runs it unmeasured and measures the libraries. A run that measures nothing at all fails with "Nothing was measured".
- **Unloaded libraries can still be reported.** List a DLL under `baseline` to see it at 0% when no test loads it. When a run does load it, its hits are merged into the same module.
- **It works with the rest of covdbg.** Target-specific `extend` and `override` apply to `modules`, and with `follow_children` the selection covers every followed process. AI agents connected through `covdbg mcp` find a new `libraries` topic in the built-in guide.

[Read the shared library documentation](/docs/reference/configuration/#shared-library-patterns).

## Sign in for one team

If you belong to more than one team, it was not always obvious which one a run counted against. In 1.4.0 a sign-in is for one team. `covdbg login` ends with a step in the browser where you choose it, or you name it up front:

```powershell
covdbg login --team northwind-robotics
covdbg login --team personal
```

covdbg confirms the choice with `Signed in as <email> for <team>.` To switch teams, sign in again for the other one.

`covdbg whoami` now asks the service who the machine is signed in as, and for which team. If the service cannot be reached, it shows the stored sign-in and says that it could not confirm it. Scripts and tools can use `covdbg whoami --json`, which prints the same answer as one JSON object.

When a run is refused, the message names the account and the team it was decided for, so a missing seat is easy to spot. A sign-in or project token that the license service rejects is now refused with a message to run `covdbg login`, instead of running on the cached offline decision. An unreachable service still uses the cached decision, as before.

See [the sign-in commands](/docs/reference/cli-reference/#subcommands-login-logout-whoami) and the [licensing FAQ](/docs/reference/licensing-faq/).

## Moving to 1.4.0

1. Install covdbg 1.4.0.
2. Run `covdbg whoami`. If it names no team, or not the one you want, run `covdbg login --team <slug>`.
3. To measure DLLs, add `modules.include` to `.covdbg.yaml` and make sure the libraries' sources pass `files`.

CI runs with `COVDBG_PROJECT_TOKEN` need no changes. The full list of changes is in the [changelog](/docs/reference/changelog/).

## Try it with your project

[Download covdbg](/download/) and follow the [quick-start guide](/docs/getting-started/quick-start/). If you have questions about measuring your libraries or setting up your team, email [our support team](/company/contact/#email-addresses).