Dev drive not mounted after reboot

[rageshkrishna]

Dev Home version

0.601.297.0

Windows build number

10.0.22631.0

Other software

No response

Steps to reproduce the bug

• Create a dev drive
• Store some code on it
• Reboot the machine

Expected result

The dev drive should be mounted after the reboot

Actual result

The dev drive is missing.

I am able to mount the VHD manually and it restores it to the right drive letter, but I'm unsure why this doesn't happen automatically. I have another machine where this works as expected and the mounted dev drive is available after reboots.

Included System Information

No response

Included Extensions Information

No response

[niikoo]

I have the same issue. Made a scheduled task to mount it as a workaround.

[jimmychanga]

I'm also experiencing this issue. Oddly enough I have another VHD with VMs on it that mounts automatically after a reboot.

[skanda890]

The Virtual Disk gets automatically dismounts when the computer reboots.

[jimmychanga]

The Virtual Disk gets automatically removed when the computer reboots.

That is not true, as I stated in my OP, I have 2 VHDs. One remains mounted after reboots, the dev drive does not.

[skanda890]

I have done the same thing. I think I found the reason behind this:

Because the one which is still mounted is because something is stopping it from dismounting, but the other one is not getting mounted because, nothing is stopping it from dismounting. The one which is not getting dismounted should be a in a Storage Pool or something like that.

[seppestas]

I have the same issue, a colleague mentioned his dev drive remounts on reboot.

[JonathanBout]

Same problem over here!

I have the same issue. Made a scheduled task to mount it as a workaround.

@niikoo how did you do that exactly?

[niikoo]

This is how I set it up @JonathanBout

Task Scheduler

General Name: Auto-Mount DevDrive VHDX at Startup When running the task, use the following user account: [I selected an account with administrative rights] Selected Run whether user is logged in or not , Do not store password and Run with highest privileges.

Triggers

• At startup
• At log on

Actions Action: Start a program Program/script: diskpart.exe Arguments: /S "C:\devdrive.automount.diskpart"

Conditions Unchecked everything.

Settings Checked the top 5 checkboxes. Set Do not start a new instance on the last dropdown.

Create the diskpart file

Path: "C:\devdrive.automount.diskpart" File contents:

select vdisk file="C:\devDrive.vhdx"
attach vdisk
exit

Replace "C:\devDrive.vhdx" with the path to your DevDrive VHDX file.

[JonathanBout]

@niikoo thank you, it works great!

[skanda890]

The Virtual Disk gets automatically removed when the computer reboots.

That is not true, as I stated in my OP, I have 2 VHDs. One remains mounted after reboots, the dev drive does not.

@jimmychanga, does the one which stays still, in a storage pool.

[niikoo]

Close this if fixed.

I don't see a workaround as a fix, @skanda890. Hope to get a proper fix that works out of the box.

[jimmychanga]

No, it is not. It is a NTFS formatted local vhd. The only difference between the two are that the DEV drive is formatted with ReFS.

Get Outlook for iOShttps://aka.ms/o0ukef

---

[mdsharpe]

Happening to me too, though intermittently. It seems random whether the dev drive is mounted on boot or not.

[AdamBraden]

For everyone that is experiencing this problem, can you open a Feedback Hub issue under Developer Platform->Dev Drive and collect traces? Then post the link here.

Thanks, Adam

[griffi-gh]

I unmounted my dev drive in order to optimize the vhdx file, when i mounted it back it won't automount after a reboot.
Also, i can't create new dev drives, they just end up in RAW format and won't work unless i manually format them as NTFS (which defeats the whole point of dev drives)

[ChandKV]

Hi @griffi-gh, sorry to hear that. I wonder if the vhdx file was attached using diskmgmt.msc or other tools. If so, could you please detach the vhdx file using diskmgmt and retry attaching it using the System\Storage\Disks & Volumes Settings UX page? The behavior to auto-mount the vhdx files on reboot needs to be explicitly opted in and only the Settings UX for Disks & Volumes is updated to request the new behavior.

For the intermittent issue, thanks for reporting this. It will be more helpful to have the Feedback filed like @AdamBraden suggested as that would include the required logs. In this case, the System event log should have additional info on why the attempt to attach the vhd(x) failed.

[seppestas]

The behavior to auto-mount the vhdx files on reboot needs to be explicitly opted in and only the Settings UX for Disks & Volumes is updated to request the new behavior.

This explains why it doesn't work for me. I mount the volume using explorer or from a shell script, mounting it through Settings does not work for me (probably due to some company managed policy).

[nzain]

Due to company-wide security policies dev drive creation via settings panel is not possible. For testing this feature, we used an elevated powershell with something along new-VHD ... | Mount-VHD | ... to create the dev drive. Its gone after a reboot.

[citelao]

The behavior to auto-mount the vhdx files on reboot needs to be explicitly opted in and only the Settings UX for Disks & Volumes is updated to request the new behavior.

Indeed, there is a new _ATTACH_VIRTUAL_DISK_FLAG called ATTACH_VIRTUAL_DISK_FLAG_AT_BOOT, added sometime around the end of 2023. You can pass this argument to AttachVirtualDisk to auto-mount VHDs. WIM and PowerShell have not been enlightened to do this.

I've written a sample C# app that will enable auto-mounting for a given VHD(X): citelao/automount-vhd. Most of the code is written by my friend @jazzdelightsme; I adapted it to CsWin32.

Note: I work for Microsoft, but I do not own these APIs.

[nzain]

The behavior to auto-mount the vhdx files on reboot needs to be explicitly opted in and only the Settings UX for Disks & Volumes is updated to request the new behavior.

Indeed, there is a new _ATTACH_VIRTUAL_DISK_FLAG called ATTACH_VIRTUAL_DISK_FLAG_AT_BOOT, added sometime around the end of 2023. You can pass this argument to AttachVirtualDisk to auto-mount VHDs. WIM and PowerShell have not been enlightened to do this.

I've written a sample C# app that will enable auto-mounting for a given VHD(X): citelao/automount-vhd. Most of the code is written by my friend @jazzdelightsme; I adapted it to CsWin32.

Note: I work for Microsoft, but I do not own these APIs.

Thank you @citelao ! That finally works like a charm. And thanks for putting your code onto github - running code on admin shell is nothing you would do without trust. Quickstart for anyone else:

• git clone https://github.com/citelao/automount-vhd
• inspect the source (its not much), and dotnet build -c release
• unmount your dev drive to avoid sharing violation exception, make note of the path-to-your.vhdx file
• open powershell in administrator mode and cd <somewhere>\automount-vhd\bin\Release\net8.0-windows
• ./automount-vhd.exe 'path-to-your.vhdx'
• disable your terrible autostart script workaround and reboot to enjoy :)

[nzain]

Unfortunately, it seems this worked only once :-( Now, the script has no effect other than mounting the dev drive. Its gone after a reboot. However, I'm not sure if my company has some weird group policies that interfere somehow.

[JosiahBradley]

Hi @griffi-gh, sorry to hear that. I wonder if the vhdx file was attached using diskmgmt.msc or other tools. If so, could you please detach the vhdx file using diskmgmt and retry attaching it using the System\Storage\Disks & Volumes Settings UX page? The behavior to auto-mount the vhdx files on reboot needs to be explicitly opted in and only the Settings UX for Disks & Volumes is updated to request the new behavior.

For the intermittent issue, thanks for reporting this. It will be more helpful to have the Feedback filed like @AdamBraden suggested as that would include the required logs. In this case, the System event log should have additional info on why the attempt to attach the vhd(x) failed.

Differentiating VHDX files is a dangerous act that leads to these exact bugs. There is no need to treat them differently, and if they truly are different then don't use the same underlying format, make a new one. I should be able to use my VHDX file between VMs, as a dev drive etc as that is what the format is for. Having one UI do one thing with hidden flags and another do another thing is not only inconsistent but how we get security issues etc. down the road as no one checks what the other system did. Respect the API as created.

I just started using dev drives and ran into this exact issue, of course after creating my VHDX via diskman. Forcing me to use the new clunky UI for the same tech (or worse preventing me from using PowerShell) is a scary future indeed.

[matt-gribben]

This has just started happening to me this week since rebuilding my machine / fresh Windows install

[adrastogi]

@matt-gribben would you mind filing a report from the Feedback Hub? You can log it under the 'Developer Platform -> Dev Drive' category and use the share option to include a link to it here. Thanks!

[matt-gribben]

@adrastogi https://aka.ms/AArjf34 there you go

[rickhoskins]

Your dev drive file needs to be on a permanent drive in order to be mounted on boot. If, like me, using a surface tablet, you have a SDHC card permanently in the machine, well, no good to put the dev drive file on that and want it to automount on boot. Moved the file to the C: drive and mounted it, and it automounts on boot now.

Sigh.

[AdamBraden]

@rickhoskins - putting a Dev Drive VHD on an SD card is not going to give you the perf benefits of Dev Drive compared to your SSD. Can you help me understand your desired scenario? If perf is not a major concern, you could just create a normal VHD and use a scheduled task to get it to mount - or put your content directly on the SD card. You could then use a folder exclusion to minimize Defender overhead (and do scheduled scans at appropriate times for the security threat/risk your project requires).

[rickhoskins]

@rickhoskins - putting a Dev Drive VHD on an SD card is not going to give you the perf benefits of Dev Drive compared to your SSD. Can you help me understand your desired scenario? If perf is not a major concern, you could just create a normal VHD and use a scheduled task to get it to mount - or put your content directly on the SD card. You could then use a folder exclusion to minimize Defender overhead (and do scheduled scans at appropriate times for the security threat/risk your project requires).

The external card is one of the new fast SHXC or whatever types, but yeah it's slower than an SSD. The SSD in my tablet is not big, it's a 240gb, so I started off putting the dev drive file on the SDXC with the space on it. Yes, I could mess about with defender and whatever else to get some of the benefits without using the dev drive but convenience, ease of use, interest, and also portability, I was considering duplicating the drive once I had my basic dev stuff set up on it / from it. As well as hoping to get benefit of not running all the little tiny code files and git files from NTFS, getting some speed benefit from the new drive format.

Anyhow, I have enough space to put the d-drive on the SSD so I have done so, thus allowing it to auto mount. I thought it might be useful for others to know that it won't automount on a removable drive even if that drive is basically permanent - and those could be external SSDs or even just spinning rust for some folks I guess. It wasn't mentioned here that this might be a reason for what folks are seeing - even with various steps taken, their drives don't mount on boot.

No action is needed for my scenario or in response to my post :) I am using the dev drive happily in my setup now ... until windows.old take all the space again. My fault for being in W11 dev channel :)

[JosiahBradley]

Is the only way to get traction on this the feedback hub? And if so why is there this Github repo if our bug reports come back with no response. The Dev Drive concept is fairly DOA if you can't even mount things to it. I still have to manually mount my dev drive on every single reboot, which for me is often as I do not leave my computer on when I am not using it.

[AdamBraden]

@rickhoskins - thanks for the information on your scenario. The isolation and portability of a dev drive vhd is interesting to explore if more devs operate this way.

@JosiahBradley - we are working with the file system team to fill in the gaps in the tools that support mounting and dismounting drives to ensure they support automount of a dev drive vhd. I cannot comment on a timeline at this time.

[Mukul1127]

This is how I set it up @JonathanBout

Task Scheduler

General Name: Auto-Mount DevDrive VHDX at Startup When running the task, use the following user account: [I selected an account with administrative rights] Selected Run whether user is logged in or not , Do not store password and Run with highest privileges.

Triggers

• At startup
• At log on

Actions Action: Start a program Program/script: diskpart.exe Arguments: /S "C:\devdrive.automount.diskpart"

Conditions Unchecked everything.

Settings Checked the top 5 checkboxes. Set Do not start a new instance on the last dropdown.

Create the diskpart file

Path: "C:\devdrive.automount.diskpart" File contents:

select vdisk file="C:\devDrive.vhdx"
attach vdisk
exit

Replace "C:\devDrive.vhdx" with the path to your DevDrive VHDX file.

Here's my Task that doesn't need a extra file:

General Name: Mount DevDrive. When running the task, use the following user account: I just selected my windows user Select Run whether user is logged in or not and check Do not store password and Run with highest privileges.

Triggers Add At startup and At log on

Actions Action: Start a program Program/script: powershell Arguments: Mount-DiskImage -ImagePath "C:\DevDrive.vhdx"

Conditions Uncheck everything.

Settings Check everything except the last checkbox.

Replace C:\DevDrive.vhdx with the path to your DevDrive VHDX file.

[yashints]

This just happened to me too, I cloned the git repo @citelao shared and it worked, however, I am interested in the feature in Dev Home to mount an existing disk instead of always creating a new one

[johnkennyuk]

Problem here too, cannot say exactly how long ago it my Dev Drives stopped Automounting, but they used too????

I too had to resort to a PS1 script as a workaround, but ideally, I would not have to use this measure. Has anyone found the root cause rather than just solutions???