Windows disk identity collision

Windows can keep a disk offline when its MBR signature or GPT identifier collides with another attached disk.

Cloning a disk duplicates more than files: it can copy the disk signature, GPT GUIDs, partition identifiers, boot records, and filesystem identities. Windows may offline one copy to prevent ambiguous mounting.

Start a recovery case Call 682-325-7712

Understand the symptom

A collision is an identity conflict, not proof that the offline disk is empty or corrupt.

WHY

What is happening

Microsoft reports Collision as a disk offline reason and provides uniqueid to display or set MBR signatures and GPT identifiers. Changing identity can be legitimate for a disposable clone, but dynamic disks, boot configurations, BitLocker, software licensing, snapshots, and applications may reference existing identifiers. Recovery first verifies content and chronology.

What you may see

Symptoms that change the recovery path.

Disk Management shows Offline

The reason may state a signature collision with another online disk.

Problem began after cloning

Both devices now present the same disk identity.

Only one copy gets drive letters

Windows avoids mounting two identities simultaneously.

Boot entries point to the wrong copy

Firmware or BCD paths may resolve unpredictably when duplicates are attached.

Protect the source

Actions that can make the situation worse.

Changing the original ID breaks references

Boot, encryption, dynamic-disk, and application mappings can depend on it.

Both disks online invite writes

Background services can alter the source and clone differently.

Disk order can be misidentified

A model or capacity match does not prove which copy is newer.

Do this now

Safe steps before evaluation.

Disconnect one disk

Prevent simultaneous writes while identifying source and clone.

Record serials and connection paths

Map physical device, model, serial, port, capacity, and clone date.

Preserve identity information

Capture unique IDs, partition GUIDs, BitLocker status, BCD, and Disk Management state.

Work from a verified duplicate

If an ID must change, apply it only after the authoritative source is protected.

NEPFOSYS process

How a data-first evaluation proceeds.

Identity and chronology review

NEPFOSYS distinguishes original, clone, snapshot, and current data state.

Source preservation

The authoritative disk is protected before identifier or mount changes.

Controlled clone activation

A working duplicate can receive a new identity after dependencies are understood.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Does offline collision mean data loss?

Usually it is a protective identity conflict, but verify the disks before changing anything.

Can I use DiskPart uniqueid?

It can change a disk identifier, but use it only on the intended protected clone after reviewing dependencies.

Why keep only one copy connected?

It reduces ambiguity and prevents background writes while source and clone are identified.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case