Using a Windows 10 ARM VM with FRC Game Tools Causes Bricking

Hey FRC enthusiasts!

I’ve recently switched to a Macbook (M1) and find myself unable to use the game tools in a Windows VM. Everything else works (even the app installation) but when rebooting it seems that the game tools have somehow bricked the boot device, the only error being INACCESSIBLE_BOOT_DEVICE. I’ve attempted repair via chkdsk and sfc to no avail.

Let’s break this down a bit. Windows for Arm is a bit of a weird area for lots of things right now - in fact, it’s so much a weird area that Microsoft doesn’t actually provide licensing for running it as a VM. There might or might not be a licensing exception for Arm based devices originally sold with Windows but that doesn’t matter in this case.

So with that in mind, I’m not sure which Windows for Arm VM image you are using but I would wager you are using Parallels to run it on an M1 based Mac. That might matter in terms of who you should reach out to for support for this issue… I’m genuinely curious how much support Parallels will provide you on it so if you go that route, post an update.

I’m shocked the installer runs to start with but I’m guessing either the checks for architecture are being bypassed or they aren’t being run. I’m also going to guess that the box for disabling fast startup is being left checked, which is what is ultimately causing this issue. It’s the only thing that I’m aware of in the installer that touches anything to do with startup… though there could be something else buried in the bowels of the installer - I haven’t ever stopped to pick it apart and examine every file it touched. You can try running the installer and leaving that box unchecked to see if it completes but I would wager you’re still going to run into issues.

You might try booting in safe mode as it may be an incompatible (non-ARM) driver issue.

I am indeed running this in Parallels, using the latest insider dev build for x86_64 support. This isn’t isolated to Parallels and can be replicated on other VM platforms like QEMU. It correlates directly with my installation of the FRC 2020 Game Tools, both with Fast Boot and without. WPILib otherwise works.

EDIT: Clarified x86_64 rather than just x64.

So the thing about Type 2 hypervisors on MacOS is that they need to run with a particular framework since kernel extensions have mostly been made obsolete: Apple Developer Documentation

I don’t think your issue is the hypervisor at all in this case though but since you are using Parallels, you might want to consider shaking the Parallels support tree to see what falls out.

My first guess was fast startup but it sounds like you’ve tried that and I did say, you’d likely still have issues. It’s likely something to do with what is being installed. You might want to grab Process Monitor for the installation and see what is getting written to that is causing the corrupted boot failure that this looks like.

I’ll try that, I’ve posted something on the NI forums as well as I think the issue might be partly there somehow. It’s not isolated to Parallels, but that being said, the fact it’s the same hypervisor might not matter much (in the terms of seeing if it’s a virtualization app-specific issue)

1 Like

Running insiders also means this could be a bad interaction between NIs drivers and windows. Especially with how unsupported of a configuration all this is I’m not at all surprised it completely fails. It could be a failure in so many components.

Will give stable a try, was having issues with the 32-bit only emulation in the PR channel.

Update: This appears to be an issue with LabView requiring SSE2 (though it’s supposedly supported). Not sure on next steps, guess I’ll have to wait for now.

Was this working in x86 versions of Parallels? If so, could you install that using Apple’s translation layer and then try to install Windows and the Game Tools?

The x86 Parallels might not even work on the M1 Mac to be honest with Apple’s new hypervisor system and the prevention of kernel extensions.