My E01 opens but shows no partitions. Is it empty?

Probably not. Either the partition table was wiped (look for filesystems by signature at sector 2048), the sector size is being assumed wrong, or you opened a logical-evidence E01 that contains files rather than a full disk image. Check the volume section's sector count against the file size first.

Do I need all the .E01, .E02, .E03 files to open the image?

Yes. EWF spreads its data across numbered segments and the offset table in the first file points into the later ones. Open only the first segment and any read past it fails. Keep the whole set together.

The tool says the hash doesn't match. Is the image useless?

Not useless, but compromised as evidence. A hash mismatch means the media data changed since acquisition — corruption in transit or storage, or tampering. You can still triage the contents, but flag the mismatch prominently and don't build conclusions on the affected regions.

Why your disk image won't open

A disk image that won't open is rarely a mystery once you stop guessing and read the first few hundred bytes. Most failures fall into a handful of buckets, and they're fast to tell apart. Here's the order I work through them.

It's not the format you think it is

The single most common cause. Someone hands you a file called evidence.img and it's actually an E01. Or a .dd that's really a VMDK. Extensions lie; headers don't. Read the first bytes:

EWF / E01 begins with the EVF signature EVF\x09\x0D\x0A\xFF\x00 (or LVF for logical evidence, or EVF2 for the Ex01 variant).
raw / dd has no header at all — it starts directly with the MBR or the filesystem. That's a feature and a curse: nothing identifies it, so a raw opener has to look for partition or filesystem structure instead.
VMDK starts with KDMV (a sparse extent) or is a short text descriptor pointing at extent files.
VHD has its 512-byte conectix footer at the end of the file; VHDX starts with vhdxfile at offset 0.

If you point an E01-only reader at a VMDK, it fails on the missing signature and the error is usually unhelpful. Identify the real format first.

You're missing half the image

Forensic images get split — .E01, .E02, .E03, or image.001, image.002 for split raw. The split is arbitrary, a leftover habit from FAT32 and CD-R size limits, but the data genuinely spans all of them. The offset table in the first EWF segment points into later segments, so a chunk that physically lives in .E07 is unreachable if you only opened .E01. Symptom: the image opens, metadata reads fine, and then reads fail partway through — usually right where the first segment ends. Select the whole set.

A missing segment in the middle of the set is worse: everything before it works, everything after the gap is unreachable. If you're handed segments 1 through 6 and 8, segment 7's absence costs you a contiguous chunk of the media.

The sector size is wrong

If the partition starts point into garbage, or the declared media size is exactly eight times the file size (or one eighth of it), you're assuming the wrong sector size. 4Kn drives use 4096-byte logical sectors; tools that hardcode 512 misplace every offset by a factor of eight. The MBR still reads — it's at offset 0 regardless — but every partition it describes points nowhere. Try parsing at 4096 and see if the GPT EFI PART signature suddenly lands where it should.

The acquisition was truncated

Acquisitions die. The host loses power, the destination fills up, the source drive fails mid-read. You're left with an image whose metadata claims 500 GB but whose file is 312 GB. The partition table, written early, describes partitions that run off the end of what was actually captured. Reads into the missing tail either error or return zero-padding that a careless tool treats as real data.

Compare the declared size — sector count times sector size from the volume metadata — against the actual file size. A large gap means truncation. You can still work the part you have; you just need to know where the cliff is and treat everything past it as absent, not empty.

It's genuinely corrupt

Bad sectors on the source, bit rot in storage, a botched transfer. In EWF this shows up as a chunk that won't decompress or whose CRC fails. The right behavior is not to abort the whole image — zero-fill the dead region, flag exactly which sectors are untrustworthy, and keep going, because the rest of the filesystem is almost always intact. If the primary offset table itself is damaged, fall back to the table2 backup before giving up.

And if the image carries a hash, verify it. A mismatch between the recomputed MD5/SHA and the value stored at acquisition tells you corruption is the actual problem — not the opener, not the format, not your sector size. That single check saves a lot of wasted time chasing the wrong cause.

When it's the partition table, not the image

Sometimes the image is fine and the table is the problem. A wiped MBR shows an opener nothing even though intact filesystems sit behind it at sector 2048. A zeroed primary GPT header is recoverable from the backup at the end of the disk. If the structured opener gives you an empty tree, drop down a level: read offset 0x1BE for MBR entries, LBA 1 for EFI PART, and if both are blank, scan for filesystem magic directly. The data is often right there — nothing was pointing at it.