extract-dwmcore-offsets

DWM Core Offset Extraction

Extract offsets from the dwmcore.dll currently loaded in IDA Pro. Follow every phase, in order. Do not skip. Do not summarize until the final phase.

Build-agnostic principles

• Never assume a class or member exists. MIL infrastructure was removed in 26H1+. Classes may be renamed, restructured, or absent between any two builds.
• Anchor-based identification — find functions by what they DO, not what they're called. MSVC mangling, inlining, and class names can all change.
• Gate before extract — before extracting offsets for any class, first verify the class still exists in the binary. If absent, report and skip that phase.
• The total offset count is fluid. Count adapts to what actually exists in the binary. Some members are added or removed across builds — never assume a fixed number.

Supporting files

• decompilation.md — read BEFORE starting Phase 1. Covers stable anchors, pseudocode patterns, virtual-function this adjustment, Create-based layout analysis, cross-validation rules, and .hpp output rules.
• classes.md — read when you need class hierarchy context. Covers inheritance relationships, member volatility tiers, known removals, and known ICF cases.

Per-offset lookup guidance

Each offset struct in dwmcoreProjection.Offsets.hpp now has inline comments documenting:

• The primary accessor function(s) and how to identify them
• Pseudocode patterns from the decompiler (both pre-22H2 ProcessUpdate and 22H2+ individual setters)
• Cross-reference functions (CChannel handlers, uDWM proxy counterparts)
• WARNING notes for easily confused members and ICF cases

When re-extracting offsets for a new build, read the comment above each struct first — it tells you exactly which function to decompile and what pattern to look for.

Phase 0 — Identify the build

1. survey_binary → record md5, path hint
2. Check OSHelper.hpp for existing build constants and revision enums
3. Feature-based classification — use these reliable checks instead of image size:

Build number scheme:

• 22H2 / 23H2 → both build 22621, distinguished by revision
• 24H2 / 25H2 → both build 26100, distinguished by revision
• 26H1 → build 28100 (26H2 may differ)

If the binary doesn't match any known row, use the closest match and note the discrepancy.

MIL infrastructure gate: starting in 26H1 (build 28100+), Microsoft removed MIL-based brush infrastructure. This affects Phase 2 (brush classes) and Phase 3's GetInterface (IDrawingContext). COcclusionContext, CDrawingContext core, and CD3DDevice still exist. Don't assume removal is total — check each class individually.

Output the build classification and expected MIL availability before continuing.

[!IMPORTANT] Do NOT blindly trust existing .hpp entries. Every offset must be independently verified from the actual IDA data.

Phase 1 — COcclusionContext (gate: any function comparing *(QWORD*)(this+N) == globalFrameId)

Gate check: find a function that compares *(QWORD*)(COcclusionContext+N) == globalFrameId. Primary accessor: IsCurrent@COcclusionContext (~30B). If absent, do not fail the gate — decompile *GetOptimizedRect* and look for the same comparison pattern:

if ( !a10 )
    v13 = (COcclusionContext *)(a1 + CDirtyRegion_OcclusionContext_offset);
if ( g_pComposition )
    v16 = *((_QWORD *)g_pComposition + globalFrameId_slot);
if ( *((_QWORD *)v13 + frameId_qword_index) == v16 )  // → GetFrameId = index × 8

The globalFrameId_slot within g_pComposition varies by build. The code always follows the same structure: load g_pComposition, add a slot offset, compare against the COcclusionContext member.

For each offset, see the comment in dwmcoreProjection.Offsets.hpp for the exact accessor function and pseudocode pattern. Cross-validate each with at least one other function. Also decompile the constructor (??0COcclusionContext) for the definitive layout.

Volatile member correlation: GetCurrentZ, GetDeviceTransform, GetDeviceTransformFlag, and GetArrayBasedCoverageSet tend to shift by the same byte delta across CUs. If all four differ by the same amount, trust the data.

Phase 2 — Brush classes (gate: TryDrawCommandAsDrawList)

Gate check: search for a ~2500-byte function with *DrawCommandAsDrawList* in the name. This function is never inlined and processes brush data. If absent → MIL brush infrastructure removed, skip entire phase.

For each offset (GetImageSource, GetOpacityValue, GetFloatResource, GetViewport, GetViewbox, GetRealizedColor), see the comment in dwmcoreProjection.Offsets.hpp.

Key cross-reference chain:

• Pre-22H2: CImageLegacyMilBrush::ProcessUpdate (single function processes all MILCMD_IMAGELEGACYMILBRUSH properties)
• 22H2+: CImageLegacyMilBrushGeneratedT::SetViewport / SetViewbox / etc. (individual setters)
• All builds: CChannel::ImageLegacyMilBrushUpdate (channel dispatcher)
• uDWM 24H2+: CImageLegacyMilBrushProxy::Update (batch proxy-side)

Phase 3 — CDrawingContext (gate: Create@CDrawingContext)

Gate check: search for *Create@CDrawingContext*. Decompile it. Record:

• Allocation size (the AllocClear argument)
• Vtable assignments — count them and note their offsets

Expected vtables in pre-26H1: CMILCOMBaseT at +0, IDrawingContext at +16, ID2DContextOwner at +24. In 26H1+: CMILCOMBaseT at +0, ID2DContextOwner at +16 (IDrawingContext absorbed into base).

For each offset, see the comment in dwmcoreProjection.Offsets.hpp.

Critical: GetWorldTransform3x2 is virtual (slot 0 of ID2DContextOwner vtable). The this pointer in the decompilation is already adjusted to the ID2DContextOwner subobject (CDrawingContext + 24). Actual base offset = subobject_offset + decompiler_offset.

Phase 4 — Remaining struct member offsets

Gate each class individually. If a class's accessor doesn't exist, skip that offset.

For each offset, see the comment in dwmcoreProjection.Offsets.hpp.

Key notes:

• CDirtyRegion_GetOcclusionContext: Already removed in 24H2+ (OcclusionContext passed as parameter instead of stored in CDirtyRegion). No build=0 — do not search for it.
• CArrayBasedCoverageSet_GetOccluderArray: Always at offset 0 within the struct.
• CArrayBasedCoverageSet_GetAntiOccluderArray: Win10 only — skip in Win11+.
• CD3DDevice offsets: Historically frozen — if thunks unchanged, trust existing values.
• CD3DSurface: w10_2004 only — skip in current builds.

Phase 5 — Vtable offsets

Gate each interface individually. If the implementing class constructor doesn't exist, skip that vtable.

Method for each: find the constructor, locate vtable assignments, read vtable bytes, verify via known anchor functions, find target slot. See dwmcoreProjection.Offsets.hpp for exact slot indices and their build variations.

Known ICF — cannot resolve automatically:

• IDeviceTarget_GetRenderTargetView: systematically merged with CPassthroughEffect/CKernelTransport symbols across multiple builds. Flag and skip every time.

CDeviceTextureTarget: Complex inheritance (possible diamond) — 9+ vtable pointers. Focus on extracting the specific offset, not full inheritance graph.

Phase 6 — Negative/Relative offsets

Gate each. These derive from vtable layout in constructors.

For each offset, see the comment in dwmcoreProjection.Offsets.hpp.

Phase 7 — Final report

================================================================
COMPLETE OFFSET REPORT — <build description>
image_size: 0x...  functions: N  MIL status: <full|partial|none>
================================================================

CHANGED FROM PREVIOUS BUILD:
  OffsetName: old → new

UNCHANGED:
  [✓] OffsetName  value  (source)

SKIPPED — CLASS/INTERFACE REMOVED:
  [✗] OffsetName — reason (e.g. "MIL brush infrastructure removed in 26H1")

ICF FLAGGED:
  [⚠] OffsetName — reason

REMOVED IN THIS BUILD (member gone, class still exists):
  [✗] OffsetName — no code accesses this member

NOT VERIFIED (accessor not found, may be renamed):
  [?] OffsetName — class may exist but accessor pattern not located

TOTAL: N verified (M changed, X unchanged), Y skipped/removed, Z ICF
================================================================

Before emitting C++: Apply output rules from decompilation.md. Member exists → add build=0 entry as the last interval boundary. Member/class removed → last entry names the last build that had it, no build=0. The absence of build=0 signals non-existence.

Only after all phases complete and report is shown, ask whether the user wants C++ emitted.