RawPDB: reading Windows PDB debug symbols without the DIA SDK

Deliberately no abstraction over the symbol data

RawPDB gives you direct access to the stream data contained in a PDB file, and it does not attempt to offer abstractions for iterating symbols, translation units, contributions and so on. The reason given is worth reading, because it is a design argument rather than an omission. Building a high-level abstraction over the provided low-level data is described as an ill-fated attempt that can never really be performant for everybody, because different tools like debuggers, hot-reload tools such as Live++, and profilers such as Superluminal need to perform different queries against the stored data. The conclusion is that the best solution is to offer direct access to the underlying data, with applications bringing that data into their own structures. If you are writing a tool that needs one specific query, this is the right shape. If you want a symbol database with a nice API, it is not.

The code comes from a hot-reload tool, not from a spec

The code is extracted almost directly from Live++ 2, a battle-tested hot-reload tool for C++. That provenance is the library's main credential and also explains its character. Live++ needs to read PDB data in a hot path, while a debugger can afford a heavyweight abstraction, which is exactly the reasoning the design section argues. The stated goal is eventually to become the de-facto replacement of Microsoft's DIA SDK that most C++ developers have to use. The DIA SDK is a COM-based interface with a rich object model, and it is the thing that is slow and awkward to work with from a modern C++ codebase. RawPDB takes the opposite approach: a small, predictable, header-and-source library you can read in an afternoon.

Memory-mapped access, and why it is fast

RawPDB works directly with memory-mapped data, so only the data from the streams you touch affects performance, and the README claims this is orders of magnitudes faster than the DIA SDK and faster than comparable LLVM code. The mechanism is straightforward: a mapped file means the OS pages data in on demand rather than the library reading a whole file into a buffer. The consequence for a user is that the cost of a query is proportional to the streams you actually read, not to the size of the PDB. The README also notes that when reading streams concurrently you will most likely be limited by the speed at which the OS can bring the data into your process, which is an honest statement of where the ceiling is. The published example output on a 1GiB PDB shows the whole Symbols pass completing in about 234ms, with the symbol record stream read alone taking about 25ms and storing 539,611 elements taking the bulk of it.

No STL, no exceptions, no RTTI, and one second to compile

The feature list is a set of constraints, and each one is a decision about what a debug data library owes its embedder. RawPDB does not need any STL containers or algorithms. It does not use exceptions. It does not need RTTI or use class hierarchies. It is small and compiles in roughly 1 second. It performs only a few allocations, and those can be overridden easily by changing the underlying macro. It compiles clean under -Wall. Those constraints together mean the library can be dropped into a tool that has its own allocator policy, its own error handling convention, and its own build settings, without a negotiation. The tradeoff is that you do the data modelling yourself, which is the same point the design section makes. If your project is a modern C++ codebase with exceptions and STL everywhere, the value of the constraints is that RawPDB imposes none of that on you.

Which streams you actually get

The supported stream data is listed precisely. From the DBI stream you get public symbols, global symbols, modules, module symbols, module lines in C13 line information, image sections, the info stream including the /names stream, section contributions and source files. There is also IPI stream data and TPI stream data. Every returned data structure is immutable, which is what makes the concurrency story work: the API gives you access to individual streams that can all be read concurrently in a trivial fashion, and there are no locks or waits anywhere inside the library. The documentation points at the LLVM PDB documentation as a good introduction if you are unfamiliar with the basic structure of a PDB file, and tells you to consult the example code to see how to read and parse the streams.

FASTLINK PDBs are out of scope, and that is not a small gap

There is one explicit exclusion, and it is a significant one. PDBs linked using /DEBUG:FASTLINK are not supported, because these PDBs do not contain much information, since private symbol information is distributed among object files and library files. That is a real limitation rather than a missing feature, because FASTLINK exists to speed up link times and incremental builds, which means exactly the developers who iterate fastest are the ones most likely to have a FASTLINK PDB. If your tool is a debugger that a developer runs against a freshly linked binary, you will hit this. A tool that analyses a shipped binary or an archive of symbols is unaffected. Everything else in the README is either a supported capability or an explicit constraint, which is unusual and welcome for a library in this space.

Building it and what the license allows

Building is straightforward for a Visual Studio shop. The code compiles clean under Visual Studio 2015, 2017, 2019 or 2022, and a solution for Visual Studio 2019 is included. The repository is small, with a CMakeLists.txt at the root, a src/ directory, a build/ directory, a raw_pdb.natvis file for the Visual Studio debugger visualisers, and the LICENSE. The licence is BSD-2-Clause, which is the permissive two-clause variant, so you can vendor it, modify it and ship it in a commercial tool with attribution and no source-disclosure obligation, which is what a library intended for embedding in other people's tools needs. The repository is not archived and the last push was on 2026-06-24, and there are no GitHub releases, so the build is consumed as source rather than as a packaged artefact.

Editorial conclusion

Adopt RawPDB if you are building a C++ tool that needs PDB symbol data quickly, such as a hot-reload tool, a profiler or a debugger front end, and you are willing to work with the raw stream structures. Do not adopt it if you want a ready-made symbol iteration API, because the library deliberately declines to provide one, and do not expect it to read a PDB linked with /DEBUG:FASTLINK. Before you commit, read the example code to see how the streams are parsed, and check that the compiler you use supports the Visual Studio versions the library is tested against.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. MolecularMatters/raw_pdb on GitHub
4. README