Determining Bad Clusters on a volume

Is there a way to determine the bad clusters on a volume that works on XP onward with the popular file systems? I have mixed results with FSCTL_GET_RETRIEVAL_POINTERS given a volume handle. It works fine on a Vista hard drive. But the ioctl fails on on a thumb drive in Vista and fails on a XP hard drive both with a GetLastError of ERROR_INVALID_PARAMETER. Am I doing something wrong or is there some way to fill in these holes? Below is a code snippet whittled down to the essentials I am using:

HANDLE handle = CreateFile(“\\.\c:”,
FILE_READ_ATTRIBUTES | FILE_READ_EA,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);

if (handle != INVALID_HANDLE_VALUE)
{
STARTING_VCN_INPUT_BUFFER in;
char out[16384];
DWORD return_len;

in.StartingVcn.QuadPart = 0;

DeviceIoControl(handle, FSCTL_GET_RETRIEVAL_POINTERS, &in, sizeof(in), out, sizeof(out), &return_len, NULL);
}

Then you need a kernel-mode driver and open $BadClus for NTFS case.

Bad clusters are rare now. Really rare. Modern disks usually die totally without ever developing bad clusters.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Is there a way to determine the bad clusters on a volume that works on XP onward with the popular file systems? I have mixed results with FSCTL_GET_RETRIEVAL_POINTERS given a volume handle. It works fine on a Vista hard drive. But the ioctl fails on on a thumb drive in Vista and fails on a XP hard drive both with a GetLastError of ERROR_INVALID_PARAMETER. Am I doing something wrong or is there some way to fill in these holes? Below is a code snippet whittled down to the essentials I am using:
>
>
> HANDLE handle = CreateFile(“\\.\c:”,
> FILE_READ_ATTRIBUTES | FILE_READ_EA,
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
> NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);
>
> if (handle != INVALID_HANDLE_VALUE)
> {
> STARTING_VCN_INPUT_BUFFER in;
> char out[16384];
> DWORD return_len;
>
> in.StartingVcn.QuadPart = 0;
>
> DeviceIoControl(handle, FSCTL_GET_RETRIEVAL_POINTERS, &in, sizeof(in), out, sizeof(out), &return_len, NULL);
> }
>
>

Assuming this is consistent - on a failing volume what happens if
a) does your volume handle have MANAGE_VOLUME_ACCESS ?
b) have you tried passing output buffer as null of size 0 and seen what error comes back ?

Satya
http://www.winprogger.com

> Assuming this is consistent

Yes, it is

a) does your volume handle have MANAGE_VOLUME_ACCESS ?

Great question. I couldn’t find documentation on this or so much as find this define in a header file. How can I do this?

b) have you tried passing output buffer as null of size 0 and seen what error
comes back ?

Same error

Bob,

The flag may be undocumented or documentation could be off. You have to do research to find out what that flag translates to. One easy thing to try might be to claim all access and see if you see success.

Satya
http://www.winprogger.com

> The flag may be undocumented or documentation could be off.

You have to do research to find out what that flag translates to.

Research where? There are exactly 5 hits on google for MANAGE_VOLUME_ACCESS. This thread, the Microsoft doc saying to use it in combination with this FSCTL, and 3 others that don’t shed any light on it. I also grepped all the header files in VS, the SDK, and WDK to no avail.

One easy thing to try might be to claim all access and see if you see success.

Obviously this would not work on the boot drive, but I did try it on a FAT32 thumb drive under vista and a removable NTFS drive under XP. No effect–received the same error 87.