Measure PC content updates

Use makepkg pack /priorpackage or packageutil compare to track update download sizes between game builds. For PC games, the /msixvc2 packaging option enables content-based segmentation: unchanged data can be reused without relying on the fixed 4 KB alignment required for efficient updates in original MSIXVC.

The examples in this article describe the October 2026 GDK. For release-specific format selection, see PC packaging improvements.

Note

For content update guidance specific to the original MSIXVC format, see Content update best practices.

Measure an MSIXVC2 update

Measure an update size between two packages: the package currently installed by players and the candidate package that replaces it.

Before packaging, verify the following conditions:

  • The source directories contain complete, deterministic builds. Don't modify either directory during the measurement.
  • Both builds use the same package identity and Content ID. The candidate package has a later package version.
  • Both builds use equivalent MicrosoftGame.config files, layout configuration, packaging options, and Intelligent Delivery tags except for intentional changes.
  • Each package and report uses its own empty output directory.

To create the packages and comparison reports:

  1. Open an October 2026 GDK command prompt.

  2. Package the currently released or baseline build.

    makepkg pack /msixvc2 /pc /d "<baseline_build>" /pd "<baseline_package_directory>" /f "<layout_file>"

  3. Package the candidate build by using the same format and packaging configuration.

    makepkg pack /msixvc2 /pc /d "<candidate_build>" /pd "<candidate_package_directory>" /f "<layout_file>"

  4. Locate the .msixvc file in each package directory. Pass the baseline package first and the candidate package second.

    packageutil compare "<baseline_package>" "<candidate_package>" /out "<report_directory>"

  5. Record the summary shown in the console, and open the .html report in the report directory. Retain the .json report with the build artifacts if you collect update measurements automatically.

The layout file is optional. If you omit /f, makepkg generates a default single-chunk layout. Use the same choice for both packages. Replace angle-bracket placeholders with your values and retain the quotation marks for paths that contain spaces.

You can generate the same reports while building the candidate package by using /priorpackage:

makepkg pack /msixvc2 /pc /d "<candidate_build>" /pd "<candidate_package_directory>" /f "<layout_file>" /priorpackage "<baseline_package>"

For MSIXVC2, /priorpackage generates the comparison reports after packaging. It doesn't use the baseline package to create the candidate package and doesn't change the resulting package or its update behavior. Don't also run packageutil compare unless you need to regenerate the reports or select a different report directory.

Read the comparison report

Use the report to answer both how much data is downloaded and which content causes the download:

  1. Record the estimated update download size from the report summary. This is the primary measurement for the baseline-to-candidate transition.
  2. Review the summary by installation tag, language, and device type. Confirm that the selected content represents the player configuration you intend to measure.
  3. Sort the file table by changed bytes. Investigate large files and files with an unexpectedly high changed percentage.
  4. For partially changed files, inspect the changed byte ranges. Confirm that the ranges correspond to intentional asset or archive changes.
  5. Compare the estimate with the amount of source content that intentionally changed. The update estimate also includes required package metadata and download-planning overhead, so it isn't expected to equal the size of changed source files exactly.

The local report measures one specific transition between the two packages you selected. Player download sizes can vary by installed package version and by the languages, device types, and Intelligent Delivery tags applicable to that player.

Compare MSIXVC2 with original MSIXVC

To evaluate the packaging option, package the same baseline and candidate source builds separately in each format. This produces four packages and two within-format comparisons:

Comparison Baseline package Candidate package
Original MSIXVC Baseline build without /msixvc2 Candidate build without /msixvc2
MSIXVC2 Baseline build with /msixvc2 Candidate build with /msixvc2

With the October 2026 GDK, omitting /msixvc2 with /pc selects original MSIXVC. For the original MSIXVC comparison, use the default test encryption or the same stable /lk key for both packages. Don't use /l, because packages encrypted with unique content licenses don't produce an accurate local comparison.

Keep the source builds, package identity, layout file, content selection, and other packaging settings equivalent across both formats. Use separate package and report directories so that packages or reports aren't overwritten.

Choose the compression setting based on what you want to measure:

  • To compare each format's default behavior, use /compress Automatic or omit /compress. MSIXVC2 uses Brotli; original MSIXVC doesn't.
  • To isolate the effect of content-based segmentation from compression, use /compress None for all four packages.

Run packageutil compare on each same-format pair. Don't compare an original MSIXVC package directly with an MSIXVC2 package as though they were successive versions.

Calculate the reduction in estimated update download size:

reduction percentage = (MSIXVC estimate - MSIXVC2 estimate) / MSIXVC estimate * 100

Record the package versions, tool version, compression mode, layout file revision, estimated download sizes, and reduction percentage with the test results. These details make measurements repeatable when the build pipeline or packaging tools change.

Investigate an unexpected estimate

If an estimate is missing or unexpectedly large, check the following items:

  • The first argument to packageutil compare is the baseline package and the second is the later candidate package.
  • Both packages use the same package identity and Content ID and were created in the same format.
  • The candidate package version is later than the baseline version.
  • Both packages use the intended layout, compression mode, Intelligent Delivery tags, and content-selection settings.
  • Generated archives and pack files are deterministic. Timestamps, file ordering, compression dictionaries, or other build-time changes can make otherwise unchanged source content produce different bytes.
  • The report's largest changed files and byte ranges correspond to intentional changes.

See packageutil compare for additional report options.

How content-based updates work

Content-based segmentation

The /msixvc2 option splits file data into variable-size segments based on the content rather than fixed block boundaries. Each segment is identified by a hash of its contents. Segments are distinct from chunks, which group files for streaming installation and Intelligent Delivery.

This approach means:

  • Moving an unchanged file between chunks doesn't require redownloading its content. The file's content hashes stay the same no matter which chunk it belongs to.
  • Reordering unchanged files within a chunk doesn't require redownloading their content. Segment boundaries are determined by content, not position.
  • Reordering chunks doesn't require redownloading unchanged file content. Installation metadata can still change.
  • Inserting or removing data doesn't cascade. Unlike fixed-block systems, a small insertion doesn't shift all subsequent blocks and force redownloads of unchanged content.

Deduplication on upload

Every segment is hashed before upload. The upload process queries the CDN to determine which segments already exist from prior versions. Only new or changed segments are uploaded and delivered to players. This deduplication happens automatically—no developer action is required.

Per-segment encryption and compression

Each segment is independently compressed and encrypted. This ensures that updating one segment doesn't affect others.

What changes when you enable the option

The following alignment and layout constraints from MSIXVC content updates don't apply to MSIXVC2:

MSIXVC constraint MSIXVC2 behavior
Align assets to 4 KB boundaries within pack files Not required. Content-based segmentation is alignment-independent.
Don't change chunk IDs or move files between chunks Layout changes don't require redownloading unchanged file content.
Don't reorder chunks or files Segment hashes identify unchanged file content independently of chunk order.
Data can't be efficiently moved Data movement is handled naturally by content hashing.
Fixed minimum hash tree overhead scales with game size Minimal overhead; partially downloadable.

Tip

The /msixvc2 option removes the need to preserve 4 KB alignment solely for PC packaging efficiency. Keep any alignment required by your engine or asset format. Packaging alignment optimizations still apply to XVC console packages.

Update size comparison

The following examples compare update sizes for the same game builds packaged in each format. Results vary with game content and build changes; measure your own builds rather than treating these reductions as guarantees.

For the test PC specifications used for these measurements and the size comparisons below, see Benchmark hardware.

Title Engine MSIXVC update MSIXVC2 update Reduction
Game A Unity 1.27 GB 71 MB ↓ 94%
Game B Unity 411 MB 49 MB ↓ 88%
Game C Custom 2.5 GB 473 MB ↓ 81%
Game D Unreal 1.75 GB 595 MB ↓ 66%

Game D was already optimized for MSIXVC content updates (CUv3), so its baseline update was smaller. The /msixvc2 option continues this evolution of update efficiency by removing the fixed-block alignment requirement.

Package overhead reduction

Every MSIXVC package includes a fixed minimum hash tree whose size scales with the total game size. This overhead is always fully downloaded with every update. For large titles, this overhead is significant:

Title MSIXVC overhead MSIXVC2 overhead Reduction
Game C (~320 GB) 2.049 GB (0.66%) 184.3 MB (0.06%) ↓ 91%

MSIXVC2 overhead can also be partially downloaded, meaning players only receive the portions of metadata that are relevant to their update.

Base game size improvements

Content-based segmentation and built-in compression also reduce base game download sizes:

Title MSIXVC base MSIXVC2 base Reduction
Game A 11.7 GB 4.2 GB ↓ 64%
Game B 918 MB 558 MB ↓ 39%
Game C 320.0 GB 270.5 GB ↓ 15%
Game D 129.9 GB 121.0 GB ↓ 7%

Titles with uncompressed content or significant duplicate data across chunks see the largest base size reductions. Titles that already compress all content and have no duplication (like Game D) see smaller but still meaningful improvements.

Padding considerations for cross-platform titles

If your title ships on both PC and console, you can use separate padding configurations or retain a shared configuration. Keep the packaging alignment optimizations required for XVC console packages and any alignment required by your engine. Measure changes before updating a shared asset pipeline.

PC packaging improvements
Content update best practices (MSIXVC)
PC package encryption and content protection
Package and upload a PC game
Make package (makepkg.exe)

  • Last updated on