Autodesk CER XML Format Reference (Pre-2025 Products)

This page documents the Autodesk CER crash report format used by products before 2025: the human-readable dmpuserinfo.xml file. For 2025 and newer, see the CER v7 .pb format reference.

What follows is the format as it exists in real crash reports from Civil 3D, AutoCAD, Plant 3D, Revit and Desktop Connector, not a spec Autodesk published. Each field carries a presence rating so you know what to expect before you write a parser: 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. Knowing a field exists is worth little if it is almost never there.

The shape of the file

One crash, one file, everything inside it. Root element is <CERInfo>, with two attributes: @ClientSemVersion (dates the CER client build, e.g. 6.3.2+20230824) and @ClientVersion (major version, 6 for this format). Both always present.

Encoding is UTF-8 XML, sometimes with a BOM, mixing attributes, elements and CDATA. Files are consistently well formed. Read it with [xml](Get-Content -Raw) in PowerShell or ElementTree in Python. DxDiag and GraphicsInfoRaw children are CDATA wrapped, so use a CDATA-aware getter with an InnerText fallback.

Section index

ProcessInfo

<ProcessInfo AvailPageFile="1BE15D000" AvailPhysicalMem="3522A1000"
             AvailVirtualMem="7FEE0DE88000" CerMode="1" ErrNo="2" LastWin32Error="0"/>

UserInfo

<UserInfo SerialNum="000-00000000" UserCanBeContacted="yes" ComputerName="PC-11617">
  <UserName value=""/> <UserPhone value=""/> <UserEmail value="user@example.com"/>
  <UserSubscription email="user@example.com" macID="{GUID}" userId=""/>
  <ErrorDescription AllowRT="1" CrashDate="06/27/2025" CrashID="1520c2d8-..." id="6"/>
  <Metrics CalendarUptime="2206861177" RequiredSend="0" WaitDur="25000"/>
  <WorkingDocument name="Hydraulics_Working_RoadsideDrainage.dwg"/>
  <Some.Other.File.dwg name="..." active="true"/>
</UserInfo>

That open-files list is the one thing the newer format has no answer for. It is also where a project number comes from once you strip the filename down, which is what lets crash data join drawing audit findings.

upipackage

<upipackage>
  <upivalue requestingapp="true" type="product" version="1.0">
    <level id="CIV3D"  name="productline">
      <level id="2024" name="release">
        <level id="{28B89EEF-7100-0409-2102-CF3F3A09B77D}" name="master">
          <level id="13.6.2053.0" name="build"/>
  ... one upivalue per installed product ...
  <upi_error .../>
</upipackage>

Only the requestingapp="true" entry is the crashing product. Newer builds routinely appear in this list as merely installed, so never take the highest version you see as the one that crashed.

OSInfo, LocaleInfo, WininetInfo

CrashHistory, MC3Info, DeviceInfo

When BackendFailed or BackendTimeout are non-zero, crash counts are floors rather than totals. This block has no equivalent in the newer format.

AppInformation, ProductInformation, GsConfig

AppCDATA

A CDATA payload with a loose structure. Every part of it is optional.

Command: LASTCMD;previous;previous...        <- first token is your last command
Clr Data:
-----CLR Version Info:
CBS / Install / InstallPath / Release / Servicing / TargetVersion / Version
-----Current Stack:                          <- usually empty
-----Last Unhandled Exception:               <- usually empty
-----Last 3 'first chance' exceptions:
-----Last-0 'first chance' exception:
System.SomeException: message\r\r\n   at Namespace.Method(...)
-----Last-1 ...
-----Last-2 ...
GDI_Objects:1983 User_Objects:1258 Process_Handles:3099

Three traps live in that block. The exception line and its at frame are separated by a doubled carriage return, so a regex written for a single one silently drops every top frame. First-chance exceptions are the last three seen in the session, not the crash chain, so they may be handled and unrelated. And a FileNotFound on an XmlSerializers assembly is .NET probing for an optional pre-generated DLL, not evidence of a broken install. I have made that call wrong in print before, so learn it from me instead of from your own bad ticket.

DxDiagInfo

All children are CDATA wrapped and always present.

GPU class comes from VendorID: 0x10DE NVIDIA, 0x1002 AMD, 0x8086 Intel (Arc only when ChipType says so), 0x1414 Microsoft Basic Render.

GraphicsInfo, GraphicsInfoRaw, GraphicsDriverInfo, VideoDriverInfo, OpenGLInfo

Intel in OpenGLInfo while NVIDIA sits in GsConfig/Card is the muxless laptop signature. Treat it as an architecture indicator, not proof of causation.

RuntimeInformation and LicenseInfo

The two companion files

CDXStackDump<guid>.xml appears alongside some crashes, sometimes more than one per folder. Each is a standalone RuntimeInformation document with the full managed exception: Exception@type, Message, StackTrace/Method per frame, and nested InnerException chains that can go several levels deep. This is where the detailed managed exception went when it stopped appearing inline. If the sidecar is there, parse it and ignore the rare inline block.

service_config.xml is the uploader’s own configuration: server/server_url, network/throttle_bytes_per_second, network/throttle_wait_timeout_seconds, network/disable_cert_verification, task/retry_count, task/retry_duration_seconds, task/abort_after_days. No crash content.

Parsing rules worth pinning to the wall

1. Memory attributes are hex. Uptimes are 100 ns ticks. CrashDate is MM/DD/YYYY.
2. Crash time comes from the file write time. The folder name is the collection date, which is not the same thing.
3. DxDiag and GraphicsInfoRaw values are CDATA. GsConfig setting values carry literal quote characters.
4. Open-files children are matched by element tag, because the tag is the filename.
5. For the managed exception, go AppCDATA first, then CDXStackDump, then the rare inline RuntimeInformation.
6. In a folder holding both XML and .pb files, treat the XML as authoritative for identity and let the .pb add the faulting module.

What this format has that v7 does not

The multi-file open-files list. The CrashHistory upload counters. The OpenGL renderer. First-class username, email and phone fields. And the upi_error signal that tells you inventory collection failed rather than leaving you to guess.

What it lacks, and v7 has: the faulting native module by name, access violation direction and null-pointer flag, a per-machine crash counter, and the user’s own typed description of what they were doing. That side is on the v7 .pb reference page.

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

Cheers, Shaan