Shrink the D Drive to Feed the C Drive the Honest Two Step Reality
Shrink D, grow C — it sounds like one job and is actually two. Here is what shrink really does to the map, why it stops early, and the second step nobody mentions.
✍️ Technical Anshu🪟 Windows 10 / 11⏱️ 7 minute read
🎥 Watch the full video — Technical Anshu fixes the low disk space problem by extending the partition, step by step
This is the most attempted and most misunderstood route in the whole extend-partition problem. The logic feels obvious: D has space, C needs space, shrink D and give it to C. The first half works exactly as advertised. The second half does not exist in Windows' built-in tools — and understanding why, plus the three legitimate ways to finish, is this entire page.
After shrinking D — the freed space lands in the wrong place
C Drive
still full, still blocked
D Drive
shrunk from 330 to 270 GB
Unallocated
60 GB - at the far end
The honest picture after step one. Shrink did exactly what it promises — and C still cannot grow, because the new free space touches D, not C.
1
What Shrink Actually Does
Shrinking a partition cuts size off its end — the right-hand edge on the Disk Management map — and leaves the released space as unallocated immediately beyond that edge. So when you shrink D by 60 GB, you get a smaller D with 60 GB of unallocated space after it. If the layout is C, then D, then free space, the block touching C's right edge is still D itself. The shrink was real, the space is real, and C remains exactly as blocked as before. This surprises almost everyone the first time, because "shrink D to give C more room" sounds like one operation. It is two, and shrink is only the first.
2
Why D Refuses to Shrink as Much as Explorer Promised
A second surprise waits inside the shrink itself: a D drive showing 150 GB free may only offer 40 GB of shrink. Windows cannot shrink past unmovable files sitting near the end of the partition — the page file, hibernation file, shadow copies (restore points) and certain NTFS system files park themselves wherever they like and pin the boundary. To see the true ceiling before you start, run diskpart, select volume D (use your letter's number from list volume), then shrink querymax. If the ceiling is too low, the honest levers are temporarily disabling hibernation and system protection on that volume and moving the page file — each a real system change with its own trade-offs, to be restored afterwards — or accepting the smaller shrink. Defragmenting does not relocate unmovable files; do not let a forum post send you down that path.
3
Completing the Job — the Three Honest Second Steps
With the space freed at the far end, one of these finishes the transfer:
Move D left-to-right: a third-party partition tool slides the whole D partition so it starts where the free space ends — placing the unallocated block against C's right edge, where Extend finally works. D's files ride along untouched. This is the route most people actually want; the mover case in this series covers the tool and its risks.
Delete and rebuild D: with D's files safely copied elsewhere, delete the D partition so its space merges with the freed block beside C, extend C, then recreate D in the remaining space and copy everything back. No third-party tool, fully built-in — paid for in copying time and care.
Skip the transfer: leave the layout alone and use D deliberately — move your libraries, games and big folders there and install new programs to D. If C's problem was user data rather than Windows itself, this solves it with zero partition surgery.
4
Order of Operations, If You Go Ahead
Back up — the safety case first, no exceptions, because steps below rewrite the layout
Check shrink querymax so the plan uses the real number, not Explorer's free-space figure
Shrink D by the amount C needs — 30 to 60 GB is the usual honest dose — and no more than you must
Apply the second step (move, or delete and rebuild) in the same sitting, while your backup is fresh and your notes are clear
Verify sizes, reboot once, and spot-check files on both drives before retiring the backup
🔴 Shrink is a donor, not a delivery: shrinking D releases space at D's far edge. Until something moves D or removes it, that space cannot touch C. Plan the second step before you shrink — otherwise you have simply made D smaller and solved nothing.
🎥 Watch the Complete Fix in the Video
Watch the shrink, the blocked extend and the working finish, in order, in the full video.
I shrank D but the unallocated space will not merge with C. Did I do it wrong?
No — you did it exactly right, and the result is exactly what Windows produces. Shrink releases space at the end of the partition you shrank, which is on the far side of D from C. Merging it into C requires moving D out of the way with a partition tool, or deleting and rebuilding D. There is no merge button you missed.
Shrink says I can only reclaim a few GB even though D is half empty. Why?
Unmovable files — the page file, hibernation file, restore-point shadow copies and some NTFS system files — sit inside the partition and Windows will not shrink past the last one. The shrink dialog's available figure already accounts for them. Temporarily disabling hibernation and system protection on that volume can raise the ceiling, but weigh the trade-off and restore the settings afterwards.
Can I shrink C's neighbour from the left instead, so space appears beside C?
Windows partitions cannot be shrunk from the left at all — shrink only ever cuts the end. Changing where a partition starts is a move operation, which is precisely the thing built-in tools do not do and third-party movers exist for.
This guide is based on the Technical Anshu low disk space and extend partition video • Stuck on a step? Ask in the video comments — you will get a reply 🙏