What does Windows error code 15152 (ERROR_PRI_MERGE_WRITE_FILE_FAILED) mean?

 
Previous Next
ERROR_PRI_MERGE_ADD_FILE_FAILED ERROR_PRI_MERGE_MULTIPLE_PACKAGE_FAMILIES_NOT_ALLOWED

ERROR_PRI_MERGE_WRITE_FILE_FAILED

Unable to create the merged PRI file.

ERROR_PRI_MERGE_WRITE_FILE_FAILED is Windows status 15152 (0x00003B30) associated with creation or final write of the merged PRI output. The system meaning is “this condition” Preserve the value at the API boundary because subsequent cleanup or logging calls can overwrite the last-error state.

Operational meaning

The key question is whether the destination can be created atomically with sufficient space, permissions, and a valid final index. The value describes creation or final write of the merged PRI output; it does not prove that the whole domain, DNS service, network, servicing stack, application package, or operating system has failed.

Likely impact: A partially written output must be deleted or quarantined and never published as a valid PRI. Record the scope that was actually tested instead of escalating from one rejected object or phase to a system-wide outage.

Where the result appears

  • This result can appear while processing creation or final write of the merged PRI output.
  • This result can appear while merging resources.pri files for an app package, resource package, or deployment image.
  • This result can appear while MakePri merge or build automation that combines package resource indexes.
  • It can appear while validation of package family, main-package, bundle, schema, and canonical output constraints.

Typical causes

  • the output path is unwritable.
  • the volume is full or quota constrained.
  • antivirus or another process locks the destination.
  • final serialization detects an internal inconsistency.

Diagnostic sequence

  1. capture it immediately after the failing or status-returning call and record whether the API uses Win32, DNS_STATUS, HRESULT conversion, or callback semantics.
  2. identify the exact target involved in creation or final write of the merged PRI output, including stable GUIDs, DNs, zone names, package identities, file hashes, policy names, or process identifiers as applicable.
  3. prove the state boundary: the destination can be created atomically with sufficient space, permissions, and a valid final index.
  4. collect output path and temporary path and free space and quota before restarting services, deleting objects, rebuilding packages, or changing policy.
  5. correlate ACL and process token with MakePri command line, input PRI inventory, package identities, schemas, file hashes, output path, tool version, and the first detailed merge diagnostic.
  6. determine whether the result is a failure, warning, informational completion, continuation request, or marker constant before choosing retry behavior.
  7. after changing one responsible condition, repeat the same smallest operation and verify both success and absence of unintended partial effects.

Evidence to preserve

  • collect output path and temporary path.
  • collect free space and quota.
  • collect ACL and process token.
  • collect file sharing and lock owner.
  • collect MakePri finalization diagnostic.

Correlate this evidence with MakePri command line, input PRI inventory, package identities, schemas, file hashes, output path, tool version, and the first detailed merge diagnostic. Preserve raw identifiers and the first detailed diagnostic: translating everything to 15152 can hide whether the cause was validation, topology, authorization, replication, policy, file I/O, packaging, or an intentional continuation state.

Recovery and retry

The recovery objective for it is to repair the destination and write to a fresh temporary file, then validate and atomically replace the intended output.

Retry only after the recorded boundary changes and prior completion is known. Read-only discovery for it can usually be repeated with bounded backoff; directory mutations, DNS updates, policy installation, servicing actions, and PRI writes require a state check first. Backoff for it cannot repair malformed input, unsupported structure, identity collision, missing authority, or incompatible package metadata.

Telemetry and support fields

  • record pri_merge_write_file_failed_operation — producing API, command, callback, or servicing phase.
  • record pri_merge_write_file_failed_target — stable object, zone, policy, package, file, or account identity.
  • record pri_merge_write_file_failed_state_before and pri_merge_write_file_failed_requested_state.
  • record pri_merge_write_file_failed_first_status — earliest component-specific code before translation.
  • record pri_merge_write_file_failed_server, pri_merge_write_file_failed_process, UTC timestamp, and correlation ID.

A support bundle for it should include decimal 15152, hexadecimal 0x00003B30, the smallest reproducible request, target identity, effective configuration, and evidence from the owning Windows component. When documenting it, remove secrets from exported logs but keep SIDs, GUIDs, package-family names, record types, and hashes when they are needed to distinguish objects.

Difference from nearby results

ERROR_PRI_MERGE_ADD_FILE_FAILED rejects an input during composition; this code fails while materializing the output This distinction determines whether the correct next step is input correction, topology repair, continuation, policy review, package rebuild, or no error handling at all.

Practical validation scenario

A build agent can read every input but lacks write permission in the package staging directory. Correcting the directory ACL allows atomic output creation. A negative test should reproduce it with the responsible condition preserved; the recovery test should alter only that condition and confirm the intended final state.

Developer and administrator guidance

Developers should model it explicitly in the result domain instead of collapsing every nonzero value into “failed.” Administrators should capture evidence before destructive remediation and use the component that owns creation or final write of the merged PRI output. Monitoring for it should suppress range markers and classify warning, informational, cancellation, and continuation values separately from terminal failures.

References

Looking for a different code? Search another status or error code.