I recently had the pleasure of trying to shrink a volume to allow enabling of BitLocker, only to be informed that I had 0 megabytes of space available for shrinking. Since the 278 Gigabyte drive had about 90% free space, this was a bit shocking, especially considering that I had just installed the operating system a few days earlier. But don't punch the screen before you have a gander at the rest of this post.
I am not going to delve into why this happens, or how to prevent or manage this completely at this point (since I have not figured all of that out just yet), but I did manage to come up with a procedure to open up the last 300 Megabytes of the disk so that I could complete my BitLocker install.
Once you have gone into the Disk Management interface to query available Shrink space, or have used DISKPART "shrink querymax" (see a full explanation of DISKPART usage elsewhere or message me for help), an event will be recorded in the application log regarding the last unmovable file. If you filter the log for an Event Source of Defrag, you will find a recent entry like this:
"A volume shrink analysis was initiated on volume (C:). This event log entry details information about the last unmovable file that could limit the maximum number of reclaimable bytes.
Diagnostic details:
- The last unmovable file appears to be: \Windows\CCM\ServiceData\Messaging\EndpointQueues\ClientRegistration\00000001.que::$DATA
- The last cluster of the file is: 0x45a9698
- Shrink potential target (LCN address): 0x455982
- The NTFS file flags are: ----D
- Shrink phase: <analysis>"
As you can see, the location and name of the file is identified. If you browse to this location in explorer and try to cut the file from it's current location and paste it on another physical drive (a "move"), you will get a popup telling you the name of the service preventing it's move, i.e., in this case, "SMS Agent Host". If you stop the service, you can move (cut and paste, not copy) the file to another physical drive and then move it right back again and restart the service. This will almost always use the first open space nearest the beginning of the disk and create more free space at the end of the disk, where the shrink occurs.
Now you can query the available shrink space again using either Disk Management or DISKPART, and if the space is still too small, review the event viewer again and continue to move files and restart services as needed until the available space is achieved. Occasionally, you might find a file locked by some system process that will be trickier to move, as I did. One file I found was locked by Windows Explorer. In this case, I opened Task Manager and killed the Explorer process, and then opened a New Task from the Task Manager menu to run a command prompt and performed the move from there. After the file is moved off and back onto the original drive location, simply open a New Task from the Task Manager menu and type in "explorer" which will revive the graphical Windows interface.
If you are especially unlucky, you might find a file that is truly difficult to move, like
"\System Volume Information\{2d100ba4-2cad-11e4-825d-3417ebae23dc}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA"
in which case you will have to work on file permissions to get that moved, if it is even possible to move with Windows running. If not, you might need Safe Mode or might even need to connect the disk to another system instead of booting up that system.
In any event, most files that are declared "unmovable" can be moved with a little fancy footwork. The files are not "unmovable", just locked in their current location by a running service, which would be a much better description in the event (Microsoft tech writers, are you listening?). :)
So don't believe that annoying little remark in event viewer and make that file obey your will!
"You cahn doo eet!" -- Rob Schneider
- Peter Trast, MCITP EA, MCITP DBA, MCT LinkIn with Peter
No comments:
Post a Comment