Windows 7 MBR system unable to view Windows 8 GPT HDD

The same issue has happened on another Windows 8 based hard drive and the drive information for that HDD is as follows

Make Toshiba, Model MQ01ABD032

The information for the HDD is as follows

Make Toshiba, Model MK6475GSX

Which is a 4Kb sector disk.
http//storage.toshiba.eu/cms/en/hdd/multimedia/product_detail.jsp?productid=415

The same issue has happened on another Windows 8 based hard drive and the drive information for that HDD is as follows

Make Toshiba, Model MQ01ABD032

Which is also 4Kb
http//storage.toshiba.eu/cms/en/hdd/computing/product_detail.jsp?productid=412

I would say that twjolson is the winner right now ) (though he may optionally wish to share part of the 1st prize with yours truly wink )

jaclaz

I would say that twjolson is the winner right now ) (though he may optionally wish to share part of the 1st prize with yours truly wink )

Well, … not until you can explain the reasoning behind it. Correlation is not necessarily causation.

I mean … the cited drives are still ATA drives. And that means 512byte sectors/logical blocks by default. ATA-7 or later allows large logical/physical sectors but the disk is still required to preserve the 'old' 'short' sector LB model 'in parallel' with the large-sector model.

That is, while Windows 8 may recognize the support for long sectors, and utilize it, by writing a physical sector 0 (4kbyte long), Windows 7 would (presumably) ignore the long sector support, and request LBA 0. And that has to correspond to the first 512bytes of the (long) physical sector 0 (assuming default block size).

Thus, if the drive is OK, there should not be a problem to write with one method and read with the other.

If some software got confused over if the wanted sector was a short one or a long one, things would not work out. Or if it recorded a long sector address when an LBA was expected. Or if some intermediate hardware translated incorrectly between the two modes of addressing.

But large sectors by itself …. no, there's got to be more to it than just that, doesn't it?

Well, … not until you can explain the reasoning behind it. Correlation is not necessarily causation.

Sure ) , hence the "right now".

However the reference that twjolson used is likely to be this one
http//support.microsoft.com/kb/2510009/en-us

Like most of MS original documents, it is very likely to only contain partial truths, but, strangely enough, it seems almost clear.
Additionally there is this blog post (supposedly by Steven Sinofsky)
http//blogs.msdn.com/b/b8/archive/2011/11/29/enabling-large-disks-and-large-sectors-in-windows-8.aspx

Now the Toshiba disks are both 4kb sectored and "Advanced Format" (or 512e)
http//storage.toshiba.eu/cms/en/support_services/advanced_format.html
but it is still possible that under Windows 8 they are considered "Native 4Kb" and as such *somehow* differently partitioned/formatted/whatever.

As well the issue with an incompatibility with the actual Tableau thingy remains a possibility, and again this is the reason why I suggested inquiring with the manufacturer and making a few tests with Winfe's, Windows 7 and Windows 8 based.

Being a GPT disk the LBA0 (even if sized 512 bytes and read correctly) contains just a protective MBR, and how the "rest" is managed is one of those things for which AFAIK there is not much shared experience (and also scarce literature) as with anything connected with UEFI and GPT.

jaclaz

I think this discussion is heading in the right direction. Having read the MS docs and Toshiba specs 4K/AF compatibility with Win 7, the write blocker, or others such as drivers etc could be part of the issue.

I think it would be interesting to to see what happens without that hardware write blocker in line. Restoring the image to a test disk (same Toshiba drive) to a Win7 system. If you get to the point where a clone of the disk is mounted to a Win7 machine (SP1 or greater) please run the Fsutil fsinfo ntfsinfo x (where x represents the drive that you are checking) command and post the results? I would be interested in seeing how this is resolved.

I can see that a platform to acquire/investigate 4K/AF drives will become a necessity. Thank you for posting this and I hope the group/I can help you to a resolution.

To continue on the same path, in the mentioned KB
http//support.microsoft.com/kb/2510009/en-us
there is a reference to this other KB, an update to 7 or 7 SP1
http//support.microsoft.com/kb/982018/en-us
which sounds like very related

This KB article introduces new storage infrastructure to support querying for the physical sector size of the storage device. Additionally, this KB article introduces support in certain key system components for these kinds of disks in order to improve performance, reliability, and general interoperability.

Particularly "issue 5"
Issue 5

Storage drivers do not support correct sector size reporting for Advanced Format disks

Many storage drivers do not support correct sector size reporting for Advanced Format disks. Updates to the following drivers are included in this hotfix
IaStorV.sys
Amdsata.sys
Nvraid.sys
Nvsata.sys
Note Other third-party storage drivers may not be updated to support these new SBC3 commands. Please contact your storage controller vendor for more information.

and the Note at the end

Note Support for Advanced Format disks relies on the disk reporting itself as having 4KB physical sectors, and relies on the Storage Driver reporting the physical sector size.

jaclaz

I am very appreciative of the suggestions you have all offered and it seems like we are moving in the right direction. I have had to testify more than usual in the last week so I have had limited time to carry out my experiments but I am going to begin those this week and hopefully will have some extra info for all of you. Once again thank you for all the help you have provided thus far.

Hello All, I have had an experience similar to this on a case in the last couple of weeks. My analysis machine is running Windows 7 Professional (x64) and one of the images I had in this case contained a Windows 8 installation. EnCase (v6.18) and FTK Imager were able to read and interpret the GPT partitioning and file system correctly, but as soon as I tried to run it through IEF (v5.7) it was unable to see any file system.

Next I attempted to mount the E01 image using FTK Imager resulting in my Windows 7 seeing that there were multiple partitions and assigning each of them a drive letter but when it came to interpreting the OS partition it just gave me a message about the volume being write-protected and would not show anything in Windows Explorer.

I then attempted the same in EnCase using PDE with the same result.

Finally, I mounted it again in EnCase with PDE, however this time I enabled caching and created a cache file for Windows to write to. This was the solution, once I did this Windows Explorer interpreted the volume correctly and IEF was able to run over this mounted drive and extracted all the internet history data for me.

I have not done any further testing or research in to this at this stage due to my current case load but it seems that the common issue here is Windows 7 believing it must have write-enabled access to the disk or partition in order for it to be correctly interpretted. When I get a chance I will take a look at the cache file that was created by the EnCase PDE process and see what is in there.

p.s. the original drive from the Windows 8 machine was a 500GB Seagate ST500DM002.

p.s. the original drive from the Windows 8 machine was a 500GB Seagate ST500DM002.

Yep, but was it a 512 bytes or a 4kb AF?

It seems like that model can be BOTH 512 byte and 4kb AF
http//forums.seagate.com/t5/Desktop-HDD-Desktop-SSHD/Seagate-Barracuda-500GB-720012-ST500DM002-512-Bytes-or-4K-sector/td-p/155383

(till now the suspicions have been around GPT partitioned 4Kb sectored drive, AF)

jaclaz

I ran fsutil command on it when it was mounted correctly and this reported 512b/sector
)