Which Drive Shows Up First in the Command Window?
You’ve probably opened a Command Prompt, typed dir or just looked at the prompt itself and wondered: *Why does Windows always start me on the C: drive?But * Or maybe you’ve seen a laptop that boots straight to D: and thought something was wrong. The short answer is “it depends on how the shell was launched and what the current working directory is.
Not obvious, but once you see it — you'll see it everywhere.
But there’s a lot more nuance behind that tiny letter you see before the > prompt. Practically speaking, in practice, the drive that appears first can affect scripts, batch files, and even the way you troubleshoot a broken system. Let’s dig into what decides that first drive, why you should care, and how to control it like a pro.
What Is the “First Drive” in the Command Window?
Once you open a Command Prompt (cmd.exe) Windows creates a new process and gives it a current working directory (CWD). The drive letter shown before the > is simply the drive part of that CWD Still holds up..
C:\Windows\System32>
If you launch the console from a different location—say, by double‑clicking a batch file on a USB stick—the prompt will start on that stick’s drive letter. The “first drive” is therefore not a fixed rule; it’s whatever directory the console inherits when it starts.
It sounds simple, but the gap is usually here.
Where Does the Initial CWD Come From?
- Start‑Menu or Shortcut – Most shortcuts to
cmd.exeinclude a “Start in” field. If left blank, Windows defaults to%HOMEDRIVE%%HOMEPATH%(your user profile folder). - Explorer Context Menu – Right‑clicking a folder and choosing Open command window here (or the newer Open PowerShell window here) sets the CWD to that folder’s path.
- Run Dialog – Typing
cmdin the Run box also starts in the user’s home directory. - Batch Files – If a batch file calls
cmd /corcmd /k, you can supply a/Dswitch to specify a starting drive.
In short, the first drive is whatever the shortcut, context menu, or script tells the new console to use.
Why It Matters / Why People Care
You might think the drive letter is just a cosmetic detail, but it can have real consequences:
- Relative Paths – Scripts that use
..\folder\file.txtrely on the current drive. If the script runs on D: instead of C:, it could point at the wrong file and fail silently. - Environment Variables –
%CD%expands to the full current directory, including the drive. Some tools parse this string to decide where to write logs. - Permissions – A drive may be mounted with different ACLs. Starting on a drive you don’t have write access to can make a batch file abort early.
- Automation – CI pipelines often spin up a fresh
cmd.exe. If the default drive isn’t what the build script expects, you’ll see “file not found” errors that are hard to trace.
Real talk: the most common support tickets I get involve “my script works on my laptop but not on the server.” The answer is almost always “the server started the batch file on the wrong drive.”
How It Works (or How to Do It)
Below is the step‑by‑step of what Windows does when it launches a Command Prompt and how you can steer it.
1. The Shell Process Is Created
When you double‑click cmd.exe or run cmd from the Run dialog, Windows creates a new process. The OS looks at the command line and the environment block that belong to that process Worth keeping that in mind. Turns out it matters..
If you pass the /D switch, the process skips the AutoRun registry keys that could otherwise change the CWD.
2. The “Start in” Property Is Evaluated
Every shortcut (.So lnk) has a Start in field. Even so, if it contains a path, Windows sets the CWD to that path before handing control to cmd. exe.
%HOMEDRIVE% = C:
%HOMEPATH% = \Users\YourName
That’s why you usually see C:\Users\YourName> right after opening a fresh console.
3. The AutoRun Registry Key Can Override
There’s a hidden gem (or pitfall) in HKCU\Software\Microsoft\Command Processor\AutoRun. If a string is stored there, Windows runs it every time a new cmd.exe starts.
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"AutoRun"="cd /d D:\\Tools"
That line forces every new console to start on D: — useful for developers who live on a secondary drive, but a nightmare if you forget it exists That's the whole idea..
4. Context‑Menu Launch Sets CWD Explicitly
When you right‑click a folder and pick Open command window here, Explorer calls cmd.exe /c "cd /d <folder> && cmd" behind the scenes. The /d switch tells cmd to change both the drive and the directory, guaranteeing the prompt matches the folder you clicked.
It's the bit that actually matters in practice.
5. Batch Files Can Change the Drive Mid‑Session
Inside a batch file, the cd command without /d only changes the directory on the current drive. To hop to another drive you must either:
D:
cd \Path\On\D
or the more concise:
cd /d D:\Path\On\D
If you forget the /d, the drive stays where it was, and you end up with a confusing mix of drives in the same script It's one of those things that adds up..
6. The Prompt Variable (PROMPT) Doesn’t Affect the Drive
You can customize the visual prompt (PROMPT=$P$G) to show or hide the drive, but that’s just cosmetics. The underlying CWD still includes the drive letter, so commands still run relative to it That's the part that actually makes a difference..
Common Mistakes / What Most People Get Wrong
Mistake #1: Assuming cd Changes the Drive
Newbies type cd D:\Projects and wonder why they’re still on C:. Because of that, the fix is cd /d D:\Projects. It’s a tiny flag, but it trips up a lot of batch scripts.
Mistake #2: Ignoring AutoRun
I’ve seen teams where a developer added an AutoRun entry to point to a network share. When the IT department later moved that share, every command window started with an error message that no one could explain. The solution? Check the registry before blaming the OS.
Mistake #3: Hard‑Coding Absolute Paths
If you write copy C:\temp\file.txt D:\backup\ inside a script that might run on a machine where the backup drive is actually E:, you’re setting yourself up for failure. Use relative paths or environment variables (%USERPROFILE%, %SYSTEMDRIVE%) instead.
Mistake #4: Forgetting the “Start in” Field in Shortcuts
A shortcut placed on the desktop may have a blank “Start in” field, causing the console to start in %HOMEDRIVE%. If you expected it to launch in D:\Dev, you’ll be confused when the prompt shows C:.
Mistake #5: Mixing PowerShell and CMD Expectations
PowerShell automatically switches drives when you Set-Location D:\. Worth adding: in CMD you have to type D: first. People switching back and forth often forget this, leading to “path not found” errors that look like a bug.
Practical Tips / What Actually Works
-
Set a Consistent Start‑in for Your Shortcuts
Right‑click the shortcut → Properties → “Start in”. Put the exact folder you want the console to begin in (e.g.,D:\Projects). This eliminates surprise launches. -
Use
/din EverycdThat Might Change Drives
It costs you a keystroke but saves hours of debugging. In batch files, replace all plaincdwithcd /dunless you’re absolutely sure you’ll stay on the same drive Took long enough.. -
Audit AutoRun Regularly
Runreg query HKCU\Software\Microsoft\Command Processor /v AutoRunandreg query HKLM\Software\Microsoft\Command Processor /v AutoRun. If you see anything you didn’t write, comment it out Most people skip this — try not to.. -
take advantage of Environment Variables for Flexibility
Instead of hard‑codingC:\Tools, use%SystemDrive%\Tools. If the system moves to a different drive, your scripts keep working. -
Create a “Reset Prompt” Batch Snippet
Add this to the top of any batch file you distribute:@echo off cd /d %~dp0%~dp0expands to the folder containing the batch file, and/dguarantees you’re on the right drive. -
Use
pushd/popdfor Temporary Drive Changes
pushd D:\Workchanges to D: and saves the previous location. Later,popdreturns you to where you started, drive included. It’s cleaner than manually storing%CD%. -
Test Scripts on a Clean Machine
Spin up a fresh Windows VM, open a plain Command Prompt (no shortcuts, no AutoRun), and run your script. If it works there, you’ve eliminated hidden drive‑changing side effects Turns out it matters..
FAQ
Q: Why does my Command Prompt sometimes start on D: after I reboot?
A: Check the “Start in” field of the shortcut you use, and look for an AutoRun entry in the registry. Both can force a different drive.
Q: Can I change the default drive for every new CMD window globally?
A: Yes. Add a cd /d D:\ line to the AutoRun value under HKCU\Software\Microsoft\Command Processor. Be aware this affects all users if you edit the HKLM hive.
Q: Does PowerShell inherit the same “first drive” logic?
A: PowerShell starts in the same folder as the launching process, but its Set-Location command automatically switches drives, so you rarely see the same confusion.
Q: How do I make a batch file always run from its own folder, regardless of how it’s launched?
A: Include cd /d %~dp0 at the top of the file. %~dp0 expands to the drive and path of the batch file itself Small thing, real impact..
Q: Is there a way to display the full path in the prompt without the drive letter?
A: Yes. Set PROMPT=$P$G to show the full path, or PROMPT=$g for just the > symbol. The drive is part of $P, so you can’t hide it without losing the path entirely.
Wrapping It Up
The drive you see first in the Command Window isn’t some mystical Windows default; it’s the result of where the console was told to start. Shortcuts, the “Start in” field, AutoRun registry keys, and the way you launch the shell all play a role.
Understanding that chain lets you avoid the classic “my script works on my PC but not on the server” nightmare, keep your batch files portable, and give you the confidence to tweak the environment without breaking everything It's one of those things that adds up..
Next time you open a console and see C: or D: staring back at you, you’ll know exactly why it’s there—and how to change it if you need to. Happy hacking!