From LBA to LCN: Which File Uses the Cluster Now?

Converting LBA to LCN lets you ask Windows which file currently uses a cluster on a verified NTFS volume. The result describes current allocation. It does not prove which file occupied the location when an older error was logged.

The calculation requires more than the LBA: you need its address origin and logical block size, the matching partition’s byte offset and length, and the NTFS cluster size. If any of these are unknown, stop before attaching a filename to the error.

This walkthrough is for a local NTFS volume in one partition on a basic disk. It does not map physical RAID or Storage Spaces member addresses through a virtual storage layout.

The workflow is: identify the disk and NTFS volume, collect their exact values, calculate the cluster number, then query its current allocation. Keep the query response and time with your original event.

Collect the values from the same storage layer

Preserve the original event’s provider, message, timestamp, and device identifier. Establish that its LBA is relative to the whole Windows disk you are investigating. A volume-relative address needs a different starting calculation.

Open Windows PowerShell as administrator for these information queries. D is an example letter; replace it with the verified NTFS volume.

$parts = @(Get-Partition -DriveLetter D -ErrorAction Stop)
if ($parts.Count -ne 1) {
    throw 'This walkthrough requires one verified partition.'
}
$part = $parts[0]
$part | Select-Object DiskNumber, PartitionNumber, DriveLetter,
    Offset, Size, AccessPaths | Format-List
Get-Disk -Number $part.DiskNumber |
    Select-Object Number, FriendlyName, SerialNumber, UniqueId,
        LogicalSectorSize, Size | Format-List

These commands do not repair or change the disk. Match the identity to the original evidence; a current disk number alone is insufficient for an old event.

Record Offset and Size in bytes. Use LogicalSectorSize only if it describes the same address space as the reported LBA. The physical sector size is not an interchangeable multiplier.

For checking the LBA’s numeric base and multiplier, see LBA to Byte Offset: Decimal, Hex, and Sector Size.

Next, in Command Prompt as administrator, query that same volume:

fsutil fsinfo ntfsinfo D:

Record Bytes Per Cluster and Total Clusters, not Free Clusters. Keep any 0x prefix: some values may be hexadecimal. Keep the full output so you can identify the volume later. Field labels and formatting can vary with Windows language and version.

This is a query, not a file system repair. If it fails because the volume is inaccessible or is not NTFS, do not guess a cluster size. A missing value does not mean zero.

Calculate LBA to LCN in your browser

Enter the verified values collected above. The calculator accepts decimal digits or hexadecimal values beginning with 0x; omit commas and units. Use Disk LBA for a block number, or Disk byte offset only when the source already gives a disk-relative byte address.

LBA mode checks one logical block; byte-offset mode checks one byte. The calculator checks the partition and NTFS cluster bounds against your inputs. It cannot identify your drive, read its files, or determine the length of an entire I/O request.

The drive letter is optional. Enter only the letter you verified for that NTFS volume to generate a command for its first cluster. You run that command on your own PC; the site does not execute it. If the values are confirmed and the calculation succeeds, continue to Query the current cluster allocation. The worked example and PowerShell method below are optional ways to check the arithmetic.

Work through one address

Here is an illustrative example, not output from a damaged drive:

Calculation example — not a command. The first conversion gives the beginning of the logical block:

Disk byte = 6,145 × 512 = 3,146,240
Volume byte = 3,146,240 - 1,048,576 = 2,097,664

The block fits inside the partition: its start is at or after 1,048,576, and its exclusive end is no later than 11,534,336.

Calculation example — not a command. Now divide the volume-relative byte position by the cluster size:

2,097,664 = (512 × 4,096) + 512
LCN = 512
Byte within that cluster = 512

LCNs start at zero. Therefore, LCN 512 is the cluster indexed 512, and the target begins 512 bytes into it.

A nonzero remainder is not automatically an error. A logical sector can begin partway through a larger cluster. Preserve the remainder rather than rounding the quotient to the nearest integer.

The LCN must also be smaller than the volume’s reported Total Clusters. Being inside a partition is not, by itself, enough to establish that a value is a valid NTFS cluster.

For a closer look at the starting point and partition bounds, see Disk Offset vs Volume Offset: Why the Starting Point Matters.

Optional: check the calculation in PowerShell

Use this optional method if you want a local, copyable calculation instead of the browser calculator. Run it in Windows PowerShell; administrator rights are unnecessary. The main block below uses decimal integers in quotes, without commas.

If your confirmed LBA is hexadecimal, this optional arithmetic-only block converts it first. Replace the example with the original 0x value:

$lbaHex = '0x1801'
if ($lbaHex -notmatch '^0x[0-9a-f]+$') {
    throw 'Use hexadecimal digits with a 0x prefix.'
}
[bigint]::Parse(
    ('0' + $lbaHex.Substring(2)),
    [Globalization.NumberStyles]::AllowHexSpecifier,
    [Globalization.CultureInfo]::InvariantCulture
).ToString()

The example returns 6145. The added zero prevents hexadecimal sign interpretation from making a nonnegative address negative. Copy the decimal result into the quoted $lba value below. Skip this conversion when your original address is already decimal.

Replace every quoted value in the main block with the corresponding verified decimal value:

$lba = [bigint]'6145'
$logicalBytes = [bigint]'512'
$partitionStart = [bigint]'1048576'
$partitionSize = [bigint]'10485760'
$clusterBytes = [bigint]'4096'
$totalClusters = [bigint]'2560'
if ($lba -lt 0 -or $partitionStart -lt 0 -or
    $logicalBytes -le 0 -or $partitionSize -le 0 -or
    $clusterBytes -le 0 -or $totalClusters -le 0) {
    throw 'Offsets must be nonnegative; sizes and counts must be positive.'
}
$diskByte = $lba * $logicalBytes
$partitionEnd = $partitionStart + $partitionSize
if ($diskByte -lt $partitionStart -or
    ($diskByte + $logicalBytes) -gt $partitionEnd) {
    throw 'This logical block does not fit inside the selected partition.'
}
$volumeByte = $diskByte - $partitionStart
$remainder = [bigint]0
$lcn = [bigint]::DivRem($volumeByte, $clusterBytes, [ref]$remainder)
$ntfsBytes = $totalClusters * $clusterBytes
if ($ntfsBytes -gt $partitionSize) {
    throw 'The reported NTFS cluster range exceeds the partition size.'
}
if (($volumeByte + $logicalBytes) -gt $ntfsBytes) {
    throw 'The logical block extends outside the reported NTFS cluster range.'
}
$lastRemainder = [bigint]0
$lastLcn = [bigint]::DivRem(
    ($volumeByte + $logicalBytes - 1), $clusterBytes, [ref]$lastRemainder
)
[pscustomobject]@{
    DiskByte = $diskByte.ToString()
    VolumeByte = $volumeByte.ToString()
    LCN = $lcn.ToString()
    ByteWithinCluster = $remainder.ToString()
    LastLCN = $lastLcn.ToString()
}

The expected values are DiskByte 3146240, VolumeByte 2097664, LCN 512, ByteWithinCluster 512, and LastLCN 512.

The code uses integer division with a separate remainder. It checks that one logical block fits within both the partition and the reported NTFS cluster range, then reports its first and last clusters. It does not validate the identity or origin of your input.

Query the current cluster allocation

Only after those checks, use Command Prompt as administrator:

fsutil volume querycluster D: 512

Replace both D: and 512 with your verified volume and calculated LCN. This asks about allocation; it does not move a file, repair the cluster, or read-test the drive’s entire surface.

Interpret the response carefully:

Preserve the exact response and lookup time. Do not interpret a command failure as “no file affected.”

A request can span multiple clusters. The LCN above identifies its first byte’s cluster only. If a verified request length is N bytes, the last cluster is the integer quotient of (V + N – 1) / C, where V is its volume byte offset and C is bytes per cluster. Check the entire request’s bounds before investigating that range.

Why a filename is not historical proof

Files can be deleted, replaced, or moved to different clusters. Windows explicitly supports relocating file clusters, and allocation can change while a volume is active.

For that reason, a filename returned today is a lead for checking the current file and its backup. It is not proof that this file caused the old event or was damaged by it. An I/O retry message also does not, on its own, establish permanent data loss.

Keep the original event, the input values, your calculation, and the current lookup as separate pieces of evidence. If historical attribution matters, preserve the storage state and seek an appropriate forensic or recovery workflow before making further changes.