Win7 Disk Management does not recognize the system volume - says 100% Free
When I try to use Disk Management, it correctly reports the size of my C: drive (80 GB) and pronounces it to be "Healthy (System, Boot, Active, Crash Dump, Primary Partition)", but it says that it has 100% free space. It will allow me to expand the volume, but if I try to shrink the volume, after a brief delay while it queries for available space, it says that I can shrink by a few 100 MB, and when I ask it to shrink, it says "The volume you have selected to shrink does not have a recognizable file system. Shrinking this volume will erase any data that you may have stored on it. Are you sure you want to shrink this volume?" Chkdsk sees no problems. Properties dialog for the C: drive reports 25 GB in use. Diskpart does not have a problem shrinking it, but when asked to list the volumes, Diskpart leaves the Label and File System columns blank for the C drive (it finds correct values for the other volumes on this same disk). FixMBR, FixBoot, RebuildBCD have not had any effect. I am concerned that something is wrong though, and if I continue to use this system in this state, I may lose data or experience file system corruption. How I got here: Received new laptop from my IT department with Win7 64-bit preinstalled, with the entire drive allocated for the C drive. Successfully used Disk Manager to shrink the C drive, but could only shrink about 50% because of an unmovable file. This seems to be a commonly encountered problem and many people have reported that PerfectDisk was able to reorganize the disk so that Disk Management could shrink it further, so I downloaded a trial copy of PerfectDisk and tried it. That is when this problem started. Customer Support at Raxco suggested FixMBR and then suggested Microsoft Support if that didn't work. Does anyone have any insight into what I need to do to correct this problem? Thanks
June 25th, 2011 1:22pm

Since you have a company issued computer, you should consult your company's IT department for assistance. Most companies have strict policies regarding the alteration of a company-owned computer by an employee.Carey Frisch
Free Windows Admin Tool Kit Click here and download it now
June 26th, 2011 6:15pm

Since you have a company issued computer, you should consult your company's IT department for assistance. Most companies have strict policies regarding the alteration of a company-owned computer by an employee. Carey Frisch Thanks for the sagely advice. If that was a realistic option, I would have already done that. The technical and political considerations in my situation that prevent that course of action aren't really relevant in this forum so please just take my word for it that I've already investigated this approach and it's not a feasible path for me to follow.
June 26th, 2011 8:39pm

Some IT departments place hidden files or partitions on their laptops, such as recovery utilities or tracking software to locate the laptop in the event it is stolen, all of which in turn can cause issues creating and resizing partitions. To correct the current problem the entire hard drive may need to be wiped clean, the operating system and software reinstalled. Something only your IT department can do. Good luck.
Free Windows Admin Tool Kit Click here and download it now
June 26th, 2011 10:53pm

Did you try using PerfectDisk's "Consolidate Free Space" option?Carey Frisch
June 27th, 2011 1:01am

Did you try using PerfectDisk's "Consolidate Free Space" option? Carey Frisch Yes. I followed steps 1 - 6 at this URL: http://wpblog.perfectdisk.com/?p=1415 After the consolidate and boot time defrag, I launched Disk Management and observed this issue. Prior to running Perfect Disk, Disk Management was working correctly. Prior to running Perfect Disk, Disk Management was able to shrink the volume 50% and reported in the event logs that it could not shrink it more than that because of the unmovable file "\$BitMap::$DATA". It seems likely that Perfect Disk moved this file, but I'm not sure if relocating this file is what has confused Disk Management or if some other change is responsible for the behavior. Using the latest version of System Internals' process monitoring tools, I observed that when Disk Management is running, it encounters one "Access Denied" error when trying to write something to "C:\". It's fairly common for these kinds of errors to occur when a process is running, so I don't know if this one is significant or not. It looks like both the System account and my own ID have full permissions for C:\, but C:\ is owned by "Trusted Installer" and I'm not able to take ownership.
Free Windows Admin Tool Kit Click here and download it now
June 27th, 2011 6:29am

This is starting to look like some sort of permissions issue. I was able to reproduce the problem on a different volume by temporarily denying write permissions to the SYSTEM account for the root directory on that volume. This results in the same symptoms in Disk Management (reports 100% free space, warns about shrinking volume on unknown file system) and the same symptoms in the System Internals Process Monitor tool: a permission denied error for disk management when trying to open a file in the volume with modified permissions. Here are the details for what Process Monitor reports for the permission denied error on the C: drive: Date & Time: 6/27/2011 1:54:00 PM Event Class: File System Operation: CreateFile Result: ACCESS DENIED Path: C:\ TID: 2588 Duration: 0.0000178 Desired Access: Read Data/List Directory, Write Data/Add File, Read Attributes, Synchronize Disposition: Open Options: Synchronous IO Non-Alert Attributes: n/a ShareMode: Read, Write AllocationSize: n/a And here are the permissions that icacls.exe reports for C:\ c:\ BUILTIN\Administrators:(F) BUILTIN\Administrators:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F) BUILTIN\Users:(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M) NT AUTHORITY\Authenticated Users:(AD) Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW) I consider myself to only be one half-step above neophyte when it comes to interpreting anything to do with icacls output, but this looks reasonable to me. As a sanity check, I asked a colleague who received a similarly configured laptop for his icacls output for C:\ and it was identical. But I also compared this to a different Win 7 box that has a more generic installation and that box had different icacls output, so maybe there is something amiss here? As an administrator, I have no problem creating new files in C:\ and the administrator permissions seem to be identical to SYSTEM permissions. I also wrote some test code that used the CreateFile API on C:\ to get a file handle on the root directory and that didn't seem to have any problems. This leaves me wondering if the permissions for C:\ might have been damaged in some way. Does anyone know a procedure or a URL that describes a procedure for replacing (possibly) damaged permissions on the root directory of the System volume? Thanks
June 28th, 2011 4:29pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics