How can I determine the sector size in windows? - windows-7

How can I determine the Physical Sector Size (e.g. if i have an Advanced Format drive with 4,096 byte sectors rather than the legacy 512 byte sectors) in Windows 7?
I know that by clicking on a file and get properties we can find out the NTFS Cluster Size, but that's not the same as the hard-drive's sector size.
Note: We ask about Windows 7 because it (and Windows Vista SP1) understand the existence of 4096 Advanced Format hard drives.

You want fsutil. Make sure you run Command Prompt as Admin.
C:\Windows\system32>fsutil fsinfo ntfsinfo c:
NTFS Volume Serial Number : 0xf4ca5d7cca5d3c54
Version : 3.1
Number Sectors : 0x00000000378fd7ff
Total Clusters : 0x0000000006f1faff
Free Clusters : 0x00000000000e8821
Total Reserved : 0x0000000000000910
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x00000000196c0000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x000000000097ffff
Mft Zone Start : 0x000000000051f920
Mft Zone End : 0x000000000051f9a0
RM Identifier: 0652C3D3-7AA9-11DA-ACAC-C80AA9F2FF32

Windows 10 update:
There is now a sectorInfo sub-command which may provide better information:
C:\>fsutil fsinfo sectorInfo C:
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 4096
PhysicalBytesPerSectorForPerformance : 4096
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 4096
Device Alignment : Aligned (0x000)
Partition alignment on device : Aligned (0x000)
Performs Normal Seeks
Trim Not Supported

i wanted to expand on Chris Gessler's answer, and note that there is no known way to get the Physical sector of a drive using Windows Management Instrumentation (WMI), e.g. wmic.
Given that i have an Advanced Format drive (i.e. it uses 4,096 bytes per sector rather than 512):
C:\Windows\system32>fsutil fsinfo ntfsinfo d:
NTFS Volume Serial Number : 0xa016d8a616d87eaa
Version : 3.1
Number Sectors : 0x00000000747057ff
Total Clusters : 0x000000000e8e0aff
Free Clusters : 0x000000000e7b2813
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 4096
Neither WMI's DiskDrive:
wmic:root\cli>diskdrive
Availability BytesPerSector Capabilities CapabilityDescriptions Caption
512 {3, 4, 10} {"Random Access", "Supports Writing", "SMART Notification"} ST1000DM003-9YN162 ATA Device
 
nor Partition:
wmic:root\cli>partition get BlockSize, StartingOffset, Name, Index
BlockSize Index Name StartingOffset
512 0 Disk #0, Partition #0 1048576
can report the underlying physical sector size. It makes sense when you realize they both report the sector size that Windows is using. It is 512 bytes per sector - the drive just happens to be different inside.
That's because only Windows 8 supports use of 4k sectors. Windows 7 understands that the drive might be 4k, and works to align it's 4k Clusters with the hard-drive's underlying 4k Sectors.
Update
wmic diskdrive now does show physical bytes per sector in Bytes per Sector:
C:\Windows\system32>wmic
wmic:root\cli>diskdrive
Availability BytesPerSector Capabilities CapabilityDescriptions
4096 {3, 4} {"Random Access", "Supports Writing"}
While wmic partition continues to be wrong.
Windows 10.0.19041.804

Run msinfo32 in command line that should popup a GUI window called
"System Information"
In the left pane select "System Summary->Components->Storage->Disks". This should load info of all drives in the right pane
Find your desired drive and check the value for "Bytes/Sector". it should say "Bytes/Sector 4096"

If you want to have it programmatically, you need to send IOCTL_DISK_GET_DRIVE_GEOMETRY_EX and use Geometry.BytesPerSector from DISK_GEOMETRY_EX structure

You can use wmic from the command line:
C:\Windows\System32\wmic partition get BlockSize, StartingOffset, Name, Index
BlockSize Index Name StartingOffset
512 0 Disk #0, Partition #0 32256
512 1 Disk #0, Partition #1 370195176960
The BlockSize is the sector size of the drive.

Powershell:
$wql = "SELECT Label, Blocksize, Name FROM Win32_Volume WHERE FileSystem='NTFS'"
Get-WmiObject -Query $wql -ComputerName '.' | Select-Object Label, Blocksize, Name
Output example:
Label Blocksize Name
----- --------- ----
OSDisk 4096 C:\
Windows RE Tools 4096 \\?\Volume{b042c778-cd66-4381-9312-3f4311321675}\
PS C:\>

If you really want to have it programmatically, you need to send IOCTL_STORAGE_QUERY_PROPERTY providing STORAGE_PROPERTY_QUERY with PropertyId set to StorageAccessAlignmentProperty. This gives both physical and logical sector sizes.
Note: this only works on Windows Vista and higher.

Recent powershell versions have a Get-Volume
Get-Volume | Format-Table DriveLetter, FileSystemLabel, AllocationUnitSize

Related

Some authentication problem while making bootable USB using rufus

In windows 10, I'm trying to install ubuntu with USB. For making bootable USB, I'm using rufus.
However, there occurs an authentication problem even though I logged in Windows with an administrator account.
Here's the log from rufus.
Will reuse 'ldlinux.sys' and 'ldlinux.bss' from './rufus_files/rufus_files/syslinux-6.03/20171017/' for Syslinux installation
Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE1 for exclusive write access
Requesting lock...
ABORTED: Cannot use an image that is located on the target drive!
\\?\Volume{d0782feb-cabc-11e8-b19e-806e6f6e6963}\ was already mounted as D:\
Re-mounted volume as 'D:' after error
Found USB 2.0 device 'Generic Flash Disk USB Device' (058F:6387)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x1F76D35D
Drive has an unknown Master Boot Record
Partition 1:
Type: NTFS (0x07)
Size: 7.5 GB (8048869376 bytes)
Start Sector: 8192, Boot: No
Found USB 2.0 device 'Generic Flash Disk USB Device' (058F:6387)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x1F76D35D
Drive has an unknown Master Boot Record
Partition 1:
Type: NTFS (0x07)
Size: 7.5 GB (8048869376 bytes)
Start Sector: 8192, Boot: No
It seems like there's some problem during locking.
How can I solve this?
ABORTED: Cannot use an image that is located on the target drive!
The line above means that you are trying to write the drive on which your ISO resides. This is the equivalent to sawing the branch you are sitting on!
Of course, Rufus cannot erase a drive if the image you want to apply resides on that drive.
Please remember that Rufus always repartitions and reformats a drive, so you cannot use anything from that drive, especially not an ISO.
The solution: Move your .iso file somewhere else that isn't the USB drive you are trying to use with Rufus.
after formatting your USB and installing windows, you have one problem after formatting your USB!
USB can't detect in mp3 player, mobile phones, and car.
solve problem =>
open Rufus
choose "MBR partition scheme for BIOS or UEFI" in the partition scheme.
unchoose "create a bootable disk usage"
unchoose "Create extended label and icon files"
click "START" for formatting your USB.

Coredump size different than process virtual memory space

I'm working on OS X 10.11, and generated dump file in the following manner :
1. ulimit -c unlimited
2. kill -10 5228 (process pid)
and got dump file with the rolling attributes : 642M Jun 26 15:00 core.5228
Right before that, I checked the process total memory space using vmmap command to try and estimate the expected dump size.
However, the estimation (238.7Mb) was much smaller than the actual size (642Mb).
Can this gap be explained ?
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 2048K 2
Kernel Alloc Once 4K 2
MALLOC guard page 16K 4
MALLOC metadata 180K 6
MALLOC_SMALL 56.0M 4 see MALLOC ZONE table below
MALLOC_SMALL (empty) 8192K 2 see MALLOC ZONE table below
MALLOC_TINY 8192K 3 see MALLOC ZONE table below
STACK GUARD 56.0M 2
Stack 8192K 2
__DATA 1512K 44
__LINKEDIT 90.9M 4
__TEXT 8336K 44
shared memory 12K 4
=========== ======= =======
TOTAL 238.7M 110
VIRTUAL ALLOCATION BYTES REGION
MALLOC ZONE SIZE COUNT ALLOCATED % FULL COUNT
=========== ======= ========= ========= ====== ======
DefaultMallocZone_0x100e42000 72.0M 7096 427K 0% 6
coredump can, and does, filter the process memory. See the core man page:
Controlling which mappings are written to the core dump
Since kernel 2.6.23, the Linux-specific /proc/PID/coredump_filter file can be used to control which memory segments are written to the core dump file in the event that a core dump is performed for the process with the corresponding process ID.
The value in the file is a bit mask of memory mapping types (see mmap(2)). If a bit is set in the mask, then memory mappings of the corresponding type are dumped; otherwise they are not dumped. The bits in this file have the following meanings:
bit 0 Dump anonymous private mappings.
bit 1 Dump anonymous shared mappings.
bit 2 Dump file-backed private mappings.
bit 3 Dump file-backed shared mappings.
bit 4 (since Linux 2.6.24)
Dump ELF headers.
bit 5 (since Linux 2.6.28)
Dump private huge pages.
bit 6 (since Linux 2.6.28)
Dump shared huge pages.
bit 7 (since Linux 4.4)
Dump private DAX pages.
bit 8 (since Linux 4.4)
Dump shared DAX pages.
By default, the following bits are set: 0, 1, 4 (if the CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS kernel configuration option is enabled), and 5. This default can be modified at boot time using the coredump_filter boot option.
I assume OS X behaves similarly.

How to fix bad dd img write to sdcard

I am trying to write 2016-05-10-raspbian-jessie.img (an image) to my SanDisk Ultra 4GB (Class? 4) SDCARD using my MacBook Pro (running OS X) for my Raspberry Pi.
When I run the dd cmd it gives some errors:
Matts-MacBook-Pro:dev Matt$ sudo dd bs=1m if=~/Downloads/2016-05-10-raspbian-jessie.img of=/dev/rdisk2
dd: /dev/rdisk2: short write on character device
dd: /dev/rdisk2: Input/output error
3782+0 records in
3781+1 records out
3965190144 bytes transferred in 635.507654 secs (6239406 bytes/sec)
I actually get the files on the SDcard but when I boot the Raspberry Pi, I get a kernel panic:
Unable to mount root filessystem on unknown block
An old forum post recommends:
adding a forcefsck to the end of cmdline.txt on the SDCard.
using fsck: sudo fsck -fy /dev/disk2, but I just get back the usage text: usage: fsck -fdnypq -l number
What is the best way to do this in OS X? My MBP is my only working SDCard reader, I can't get the commands that "should" work to work in fsck. It'd even better if you know what the cause is.
How big is the image file, and what's the actual size of the SD card? That looks like it might have run out of space on the disk, since "3965190144 bytes transferred" is 3.965 GB, which is pretty close to the nominal 4GB capacity of the card.
Note: when checking sizes there's a potential for confusion between true gigabytes (GB = 1,000,000,000 bytes) and gibibytes (GiB = 1,073,741,824 bytes) which are sometimes called gigabytes. Disk sizes are generally given in true GB, but RAM is generally given in GiB, and software tools for showing sizes are often inconsistent. When in doubt, look at the actual number of bytes. In OS X, you can get the exact disk size with e.g. diskutil info /dev/disk2.

How to WriteFile to a PhysicalDrive (Windows 7) without getting ERROR_ACCESS_DENIED?

I'm trying to write a test pattern to every sector of a formatted USB drive. There is one logical drive (e.g. h:). This volume is FAT-formatted and contains data to be overwritten. Also, I want to overwrite the whole physical drive. The program is running with elevated user rights.
First I did the following:
// from the drive letter "h:" I get the physical disk number using
// IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS => "\\.\PhysicalDrive2"
hDevice = ::CreateFile( "\\.\PhysicalDrive2", GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL );
// get the number of available sectors with IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
// => ulNumberOfSectors
// now I try to write some sectors, e.g. 2 (I want to use a higher value):
WriteFile( hDevice, abBuffer, 2*512, &byteswritten, NULL );
The call to WriteFile fails with ERROR_ACCESS_DENIED.
If I write one sector, it works.
When I overwrite the first sector and plug the device out and in again, Windows wants to format it. In this situation my code with 2048 sectors at once works without ERROR_ACCESS_DENIED.
I also unmounted the volume as described in CodeProject: WriteFile on Physical Drives with Windows 7 but this didn't change anything. Obviously the volume is unmounted because it's no longer visible in Windows Explorer.
I want to write more than a single sector due to perfomance reasons. I'm also afraid that other problems in the field might occur because I don't fully understand ths problem.
Any suggestions?
I didn't have problems with different WriteFile() sizes, but I did solve the
WriteFile(): Access is denied <ERROR_ACCESS_DENIED/5> to
'\.\physicaldriveX
devices (usually USB HDD/SSD) in Windows 7 running as Administrator (elevated rights) as follows:
Computer Management -> Disk Management:
Volume (H: in your case) -> right-click -> Delete Volume
Disk (Disk 2 in your case) -> right-click -> Off-line
Disk (Disk 2 in your case) -> right-click -> On-line
After that, I'm able to write to '\.\physicaldriveX' with no problem.
I think the Win7 locks (unlike previous Windows releases) the physical device as long as there is any file system on the device to avoid consistency problems.
You cannot directly access sectors of a drive which are owned by a mounted filesystem.
See Changes to the file system and to the storage stack to restrict direct disk access and direct volume access
The documentation for FSCTL_DISMOUNT_VOLUME describes the following sequence for overwriting a filesystem:
Open a volume.
Lock the volume.
Format the volume.
Dismount the volume.
Unlock the volume.
Close the volume handle.
Your pattern-writing operation would be in step 3 instead of formatting.
Another method is to use clean to delete all the partitions (and ALL DATA) on the disk:
C:\> diskpart
Diskpart> list disk
Diskpart> select disk N (where N is your disk number)
Diskpart> clean
Diskpart> exit

How can I view the allocation unit size of a NTFS partition in Vista?

Which built in (if any) tool can I use to determine the allocation unit size of a certain NTFS partition ?
Open an administrator command prompt, and do this command:
fsutil fsinfo ntfsinfo [your drive]
The Bytes Per Cluster is the equivalent of the allocation unit.
Use diskpart.exe.
Once you are in diskpart select volume <VolumeNumber> then type filesystems.
It should tell you the file system type and the allocation unit size. It will also tell you the supported sizes etc. Previously mentioned fsutil does work, but answer isn't as clear and I couldn't find a syntax to get the same information for a junction point.
I know this is an old thread, but there's a newer way then having to use fsutil or diskpart.
Run this powershell command.
Get-Volume | Format-List AllocationUnitSize, FileSystemLabel
Another way to find it quickly via the GUI on any windows system:
create a text file, type a word or two (or random text) in it, and save it.
Right-click on the file to show Properties.
"Size on disk" = allocation unit.
The value for BYTES PER CLUSTER - 65536 = 64K
C:\temp>fsutil fsinfo drives
Drives: C:\ D:\ E:\ F:\ G:\ I:\ J:\ N:\ O:\ P:\ S:\
C:\temp>fsutil fsinfo ntfsInfo N:
NTFS Volume Serial Number : 0xfe5a90935a9049f3
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000002e15befff
Total Clusters : 0x000000005c2b7dff
Free Clusters : 0x000000005c2a15f0
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000040000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000000000002
Mft Zone Start : 0x00000000000c0000
Mft Zone End : 0x00000000000cc820
Resource Manager Identifier : 560F51B2-CEFA-11E5-80C9-98BE94F91273
C:\temp>fsutil fsinfo ntfsInfo N:
NTFS Volume Serial Number : 0x36acd4b1acd46d3d
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000002e15befff
Total Clusters : 0x0000000005c2b7df
Free Clusters : 0x0000000005c2ac28
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 65536
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000010000
Mft Start Lcn : 0x000000000000c000
Mft2 Start Lcn : 0x0000000000000001
Mft Zone Start : 0x000000000000c000
Mft Zone End : 0x000000000000cca0
Resource Manager Identifier : 560F51C3-CEFA-11E5-80C9-98BE94F91273
Easiest way, confirmed on 2012r2.
Go to "This PC"
Right click on the Disk
Click on Format
Under drop down "allocation unit size" will be the value of what the Allocation of the Unit size disk already is.
In a CMD (as adminstrator), first run diskpart. In the opened program, enter list disk. It'll list all connected disks.
Select the right disk based on its size. If it is flash memory, usually it'd be the last item in the list. In my case, I select the Disk 2 using this command: select disk 2.
After selecting your disk, list the partitions using list partion command. You'll get a list like the one in the image below.
Now, it is time to select the right partition, based on its size. In my case, I select Partition 1 using this command: select partition 1.
Finally, you can run the filesystem command to get the Allocation Unit Size.
Note: This procedure works on both NTFS and FAT32.
According to Microsoft, the allocation unit size "Specifies the cluster size for the file system" - so it is the value shown for "Bytes Per Cluster" as shown in:
fsutil fsinfo ntfsinfo C:
You can use SysInternals NTFSInfo by Mark Russinovich from the command line and it converts fsutil fsinfo ntfsinfo into more readable information, especially MFT Table info.
The simple GUI way, as provided by J Y in a previous answer:
Create a small file (not empty)
Right-click, choose Properties
Check "Size on disk" (in tab General), double-check that your file size is less than half that so that it is certainly using a single allocation unit.
This works well and reminds you of the significance of allocation unit size. But it does have a caveat: as seen in comments to previous answer, Windows will sometimes show "Size on disk" as 0 for a very small file. In my testing, NTFS filesystems with allocation unit size 4096 bytes required the file to be 800 bytes to consistently avoid this issue. On FAT32 file systems this issue seems nonexistent, even a single byte file will work - just not empty.
from the commandline:
chkdsk l: (wait for the scan to finish)
sizdir32 http://www.ltr-data.se/opencode.html/
start > run > MSINFO32
goto components
goto storage
goto disk
on the right look for Bytes/Sector

Resources