Back in March I wrote that the move to the v7 protobuf format was the end of customer-accessible crash diagnostics. GPU config gone, memory pressure gone, session data gone. I believed it. I had the samples in front of me and the fields were not there.
They were there. I could not see them. And if you followed my instructions for reading .pb files, you have the same blind spot.
Why this is worth the effort
Neither CER format is documented by Autodesk. Working out what is in the files and what each field means is real work, and it is work you have to do yourself if you want to use crash reports to find your own causes rather than waiting on a support ticket. It pays. There is gold in CER for spotting problems with the software, with the environment it runs in, and with the drawings it is opening. The faulting module, the last command, the drawing name, the GPU the app was really rendering on, how many times that machine has crashed before. None of that is in the dialog the user sees. All of it is in the files.
What changed since March
I stopped sampling and started digesting. Every CER folder collected went through a survey script. Mostly Civil 3D, plus a smaller number of Plant 3D, AutoCAD, Desktop Connector and Revit crashes.
Then I counted. Every XML element, every .pb key, with a presence rate: the share of crash folders that actually carry it. One crash is one folder. For the XML format that is one file. For v7 it is the two or three .pb files in the folder decoded and merged into one record, so a presence rate for a .pb key means the share of crash folders where that key appears in any of the files. That number matters more than the field list does, because a field that exists in the format but shows up in three percent of crashes is not something you can build a report on.
The decode instruction that hid the data
In the v7 post I told you to run cer_rawdataviewer.exe and capture its output with 2>&1, because the tool writes its JSON to stderr. The stderr part is true.
Here is what happened in my environment. The parser is a PowerShell script that sets $ErrorActionPreference = 'Stop' at the top, which is common practice and is what I had. Under that setting, Windows PowerShell 5.1 treats each stderr line from a native executable as an error record, the 2>&1 redirect surfaces it, and the first one becomes a terminating NativeCommandError. The decode call threw. Our per-file try/catch caught it, wrote a line to the verbose stream nobody was reading, and moved on to the next folder. The script finished clean. The CSV had no .pb rows in it. Nothing looked wrong.
That ran for months. When I fixed it, the conclusions we had already written down during the broken stretch stayed in the documentation as fact.
The fix is to skip the redirect entirely. Start the process with System.Diagnostics.Process, or subprocess in Python, read StandardError directly, strip the timestamp before the first brace, parse. That path does not go through PowerShell’s error stream, so the preference setting cannot touch it. I have been bitten by this three times now, including once this week inside the survey script that was supposed to settle the question. If your parser sets the preference to Stop anywhere, check your .pb row count before you trust it.
The second mistake: reading only the keys I expected
Both my parsers pulled a list of known keys out of the JSON and ignored the rest. Nobody ever diffed the keys the decoder emits against the keys we map.
When I finally ran that diff, 130 keys came back that no parser of mine had ever touched. Some are noise. Some are exactly the fields I declared dead in March.
The drawing name is RP/Dwg. The email is RP/UserSubscriptionEmail. Session health is RP/SessionStartCount and RP/SessionEndCount. The last command is RP/LastCommand, and it is not one value, it is a chain with the most recent first. The whole AppCData block, the same first-chance exceptions and GDI counts the XML format carries, sits in RP/AppCData. All of it in the second file, rawdata-t2.pb, which is probably why nobody eyeballing rawdata-t1.pb ever noticed.
The drawing name, corrected
In the earlier viewer post I said drawing visibility had fallen from about 90 percent of crashes under XML to under 3 percent under v7. That figure was produced by the broken decode and the fixed key list together, and it is invalid. With both fixed, the XML format carries the active drawing in about 88 percent of crash folders, and the v7 format carries it in about 47 percent of genuine Civil 3D crash folders. So the drop is real, but it is roughly half, not nearly everything, and the next section is my working explanation for why. This is one of the most important pieces of info from CERs. I use it to identify potentially problematic drawings that can be causing crashes. And by mapping the drawing name I can see multiple users crashing using the same drawing and alert on it to look into.
Thin reports, and a working explanation
Plenty of .pb crashes arrive with no drawing, no command, no exception detail. A small sample makes it look like the format cannot carry those fields. Then I got two crashes from the same user, same machine, same CER client, 4 minutes apart.
The first crash, mid-session during a REGEN, carried 93 keys: drawing, command chain, first-chance exceptions, GDI counts and peaks, memory at crash, session counts, email, the faulting module. Much of the diagnostic detail I relied on in XML. The second, while opening a drawing, carried almost none of it.
What that pair proves is that payload completeness varies inside one environment, so the format is not what limits it. What it does not prove is why. My working explanation is that the RP/ keys are registered by the application after startup finishes, so a crash before that point goes out without them. It fits every thin report I have looked at, but I have not had it confirmed by Autodesk, so treat a thin report as consistent with an early crash, not as proof of one. Either way the practical consequence holds: drawing-open crashes, one of the bigger vectors any CAD manager chases, are the ones most likely to arrive without a drawing name. I have asked Autodesk to register the drawing and command earlier.
What the remaining problem actually is
The data survived the format change. The usability did not. You still need Autodesk’s decoder to read the files, there is no published documentation of the keys, and nothing in the workflow tells you the drawing name is in the second file under RP/Dwg. You find that by counting keys across a lot of crashes, which is not a CAD manager’s job. That part of the March post stands.
What I changed
Both parsers now map the recovered keys, and they keep every decoded key on the record whether it is mapped or not. Our crash viewer shows the full raw key set in its own tab, so when I am comparing two crashes the unmapped values are right there instead of thrown away. Half the time that is where the clue is.
There is also a standing audit now. It decodes the newest batch of .pb files, collects every key, and compares that list against what the parsers actually reference. Anything present in the data that nobody has either mapped or deliberately ignored fails the check by name, and the ignore list carries a reason next to every entry. When Autodesk adds a key, the next audit flags it.
Corrected guidance
- Decode
.pbfiles by starting the process and reading stderr directly. Do not use2>&1in a PowerShell script that sets the error preference to Stop. - Merge all the
.pbfiles in a crash folder before you look for anything. The drawing, command, email and session data are inrawdata-t2.pb. - Keep every decoded key on the record, not just the ones you map.
- Diff what the decoder emits against what your parser reads, on a schedule.
- Treat a thin report as a report that crashed early, and treat drawing-level statistics from v7 data as a floor.
The full field-by-field references, every element and every key with how reliably it appears, are on two pages that I will keep current: the XML format for pre-2025 products and the v7 .pb format for 2025 and newer.
Released a free CER viewer
https://btl-blog.com/2026/09/25/announcing-my-free-autodesk-cer-viewer-for-windows/
Cheers,
Shaan
