Autodesk CER v7 .pb Format Reference (2025+ Products)

This page documents the Autodesk CER v7 crash format: the binary protobuf .pb files written by 2025 and newer products, and still the current format today. For anything older, see the pre-2025 XML format reference.

What follows is the format as it exists in real crash reports from Civil 3D, AutoCAD, Plant 3D, Revit and Desktop Connector, plus the Autodesk background services that share the same client. Each key carries a presence rating: Always means every report has it, Usually means most do, Common means roughly half, Sometimes means a minority, Rare means do not count on it. Where a rating differs for genuine product crashes versus service telemetry, I say so.

One correction up front, because I published the opposite earlier this year. The v7 format did not lose the drawing name, the session data, or the user email. Those fields are in the files. They live under keys that most parsers, including mine, were never reading.

One crash, three files, two sidecars

Decoding, and the mistake that hides half the data

The decoder ships with the CER client at C:\Program Files\Autodesk\Autodesk CER\service\cer_rawdataviewer.exe. Point it at a .pb file and it prints JSON. Two rules, both learned the hard way.

The JSON goes to stderr, with a timestamp on the first line. If you capture it with 2>&1 in a PowerShell session where $ErrorActionPreference is Stop, which it is by default in the VS Code PowerShell extension and most admin profiles, every stderr line gets wrapped in a NativeCommandError and the decode throws. Your loop catches nothing and your output has no .pb rows in it at all. There is no error message you would notice. I told people to use that redirect in an earlier post, and for a stretch my own parser was silently dropping every .pb file because of it.

Start the process yourself instead. System.Diagnostics.Process with redirected streams in PowerShell, or subprocess.run(capture_output=True) reading .stderr in Python. Strip everything before the first curly brace and parse. That path does not care what your error preference is set to.

Every leaf is a list. The decoded shape is {"params": {"<key>": {"value": [...]}}}, and several keys are legitimately multi-value. Take index zero if you want one, join with a separator if you want them all, but do not assume a scalar.

rawdata-t1.pb: the crash core

The RP/ ratings here are across every .pb report, including service telemetry that never had a session to describe. In product crashes that reached a working session before they died, these keys are common. See the section on thin reports.

rawdata-t2.pb: the file that was hiding everything

If you only ever opened rawdata-t1.pb, which is the natural thing to do, this is what you missed.

Those Rare ratings are across the whole .pb population, which includes a lot of ADP, Genuine Service and installer telemetry that never had a drawing to report in the first place. Narrow it to genuine product crashes and the picture changes: the drawing name and last command show up in roughly half, and AppCData in most.

graphic-data-t1.pb: the hardware snapshot

Two traps here. This file is sometimes missing from the crash folder entirely, and when it is gone there is no GPU or system detail anywhere in the crash. And when dx.graphic names one adapter while d3d names another, you are looking at muxless or Optimus routing, which is the .pb equivalent of the XML GsConfig versus OpenGL mismatch.

Why some reports are thin, and why it is not the format’s fault

The RP/ keys are registered by the application after it finishes starting up. Crash before that point and the report ships without a drawing, a command, an email, or session counts. It is not a format limitation and it is not a client version difference. It is when the crash happened.

The practical consequence is worth stating plainly. Drawing-open crashes are one of the bigger vectors any CAD manager chases, and they are exactly the population that reports without a drawing name. Any drawing-level crash statistic you build from .pb data is a floor, not a count. I have asked Autodesk to register those values earlier in startup.

The two JSON sidecars

dialog_20260904174313.userinfo
{"user_email":"","subscription_email":"","error_description":"Opening a drawing",
 "view_test_data":0,"computer_name":"PC-11331","locale_id":1033}
dialog_20260904174324.analytics
{"session_time":31,"view_detail_button":false,"learn_more_button":false,
 "solution_url":false,"readme_url":false}

Both files always carry all their keys, though the values are often empty strings. The dialog runs after the dump, so error_description survives even when the report itself is thin. It is the most underrated field in the whole v7 package.

Identity resolution, in the order that works

1. Username from the folder path. There is no username key in .pb.
2. Product from SP/UPI_PRODUCT, then the AppInformation name inside RP/AppXML, then RP/AppName.
3. Version from SP/UPI_BUILD, then the AppXML version, then SP/UPI_RELEASE as a last resort since it is only a year.
4. Email from RP/UserSubscriptionEmail, then the .userinfo sidecar.
5. Machine name from .userinfo, then AI/os/ComputerName.
6. Crash time from the file write time. The folder name is the collection date.

A KERNELBASE breakpoint report with no UPI block and no RP/AppName cannot be identified from the .pb content at all. Classify it from the minidump or leave it unattributed. Do not guess.

Where each field lives, XML against v7

Four rows say “no equivalent.” Everything else survived the format change. It just moved to a key nobody was reading, which is a different problem with a much easier fix.

Two habits that keep this from happening again

Keep every decoded key on the record, even the ones you do not map into columns. When two crashes look identical in your mapped fields, the difference is sitting in the ones you threw away. My crash viewer shows the full raw key set in its own tab for exactly this reason.

Diff what the decoder emits against what your parser reads, on a schedule. Any key that is neither mapped nor written down somewhere with a reason for skipping it should fail loudly. When I finally ran that diff, a long list of keys came back that no parser of mine had ever touched, and the drawing name was one of them.

Reference pages get updated rather than replaced. If Autodesk adds a key or changes the client, this page changes with it.

Cheers,
Shaan