Windows 10 on ARM64 support #155
Comments
Wait, are you running the x86 version of Zadig that is published at https://zadig.akeo.ie? Also: Zadig detects a 32-bit x86 emulation (likely because that's what Microsoft used by default) and therefore tries to run the 32-bit installer, which of course the system doesn't like. For Zadig to work on ARM64, I'd have to recompile an ARM64 version and edit the embedded files to include ARM64 files. I may do that eventually, but I'm afraid I'm too busy with other stuff to look into that in the short term (short term meaning 0-6 months). Now, if somebody else wants to take a stab at it and send a patch I can review, that's a different story... |
|
Haha yeah, I was installing a batch of random laptops with SDR# for use in a school next week (for use with High Altitude Ballooning STEM project) and hadn't even crossed my mind that this one was different till I hit the error (guess is what I get for doing it this time of the night), then started digging around. What you are saying does make sense, it does only emulate x86 based apps and not x86_64 based apps full stop. |
Oh boy...
|
|
Thanks for writing this up - I am also trying to get Zadig running on Windows 10 on ARM64 to support a Lenovo Yoga C620 using an Adafruit USB-to-serial cable so I can talk to a Jetson Nano. Thanks for the detailed situation report here, I'll hope to get some help to look at this. |
|
WOW64 programs - so x86 on x64 as well as on ARM64 - can't install drivers. The API exists but just returns an error. The ARM64 SDK is supposed to be fully featured, so if you can't find the DLLs you need, let me know the SDK piece you'd expect them to be in and the path you expect the file to be at and I can talk to a friend. libusb v1 recompiles for ARM64 by just retargeting the VS projects for Windows 10. (VS2019 has some simplifications for this.) ARM64 should be pretty straightforward to add as a configuration under VS 2017 or VS 2019--I recommend 2019. You may find IsWow64Process2 handy for probing architectures, but to run on Windows 7 you'll have to use GetProcAddress to see if it's available. ARM32 support is likely not going to be useful unless you port to IoT Edition, but VS does make it easy. I just got an RTL-SDR and would be happy to test things on my Windows 10 on ARM systems, especially if there's a decent way to make sure things are uninstalled. (Just the 'delete drivers, yes' workflow in Device Manager, I expect.) (Hi @vielmetti ! If you to get some time to look at this, hit me up--I'd be happy to at least kibbitz. I think these machines have great potential for mobile maker scenarios.) (Yes, I work for Microsoft. I even work on Windows 10 on ARM(64) and have ported OSS projects as part of my day job, but I am here as a hobbyist, user, and fan and not as an employee or representative of my employer.) |
|
Hi Jon, First of all, whether in an official position or not, it's nice to know that there are some people from Microsoft looking at independent projects that relate to the installation of Windows drivers. And I'm actually glad you decided to chime in and offer to see if you can use your connections, because you may actually be able to help with the biggest roadblock I have at the moment (besides time to work on this feature) which is best illustrated by the picture below:
Namely: if you install the latest Windows 10 WDK, you still don't get any of the WDF and WinUSB coinstaller DLLs for arm64 (Still no At the very least, libwdi requires the following 2 DLLs to be provided able to support an architecture:
So, if possible, can you find out with your colleagues what the story is with regards to finally providing these files for ARM/ARM64 in the WDK, just like they are provided for x86 and x64? With regards to your other points, I agree that VS2019 has made things easier for ARM64, and I'm planning to retarget libwdi for VS2019 when I get a chance (Since I'm already using VS2019 internally). My only issue here is that, whereas AppVeyor added the VS2019 target not that long ago (but still not in an official mode), they don't have MinGW support working on that target. So if I switch from VS2017 to VS2019, my MinGW libwdi builds will break, and I'd rather not have to go through what I had to do for Rufus, which is to use a mix of 2017 and 2019 (and still end up with a Coverity that doesn't work — C'mon AppVeyor, update your platforms already!!). Apart from that, I agree that adding ARM64 support shouldn't be that difficult (as usual, it's going to be the ability to allocate time to complete that task that'll be a challenge). I'll keep in mind your recommendation to use |
|
That's what my system shows too; I'll see what I can do. |
|
Ah, that would do it. I got a quick answer: the CoInstallers are not needed on Windows 10 on ARM because the first version to ship was 1709. You can drop the references to them for ARM64. (I'm afraid I'm currently rather behind on what the coinstallers do, so I'm probably not much more help there. :/ |
|
Thanks for the info. This is actually going to make things slightly more complex for ARM/ARM64, coz we'll need to conditionally sort out a No idea when I'll have a chance to look into that, but most likely it won't be before a couple of months... I do appreciate the help however, as it solves one of the main question I had about how we might be able to proceed for ARM/ARM64. |
|
This writeup from @jkunkee gives a good state-of-the-art report, if you find this issue you'll be interested in https://daskunkee.blogspot.com/2020/02/tech-esp32-programming-from-arm64.html |
|
Please pursue it we at Windows on Rasberry Pi community will be glad to extend support in testing your drivers and tools for ARM64. We have successfully booted WOA on Rasberry Pi 4 B+ and hence have Cheap ARM64 Windows On ARM device with sort of current hardware but way cheaper than a surface pro device. |
|
Yes, I am well aware of it. I am one of the many people who helped develop the UEFI firmware needed to run Windows on the Raspberry Pi and I also helped figure out a way to run Windows off the Pi 4 USB 3.0 ports while using more than 1 GB RAM. And the reason I was involved in this effort was precisely so that I could have access to a cheap platform to test ARM64 versions of Rufus or libwdi. However, the downside of all this is that I find myself having to allocate time to maintain the Raspberry Pi firmware... which, outside of other prioritization matters (I'm afraid that libwdi will never be that high a priority for me) actually takes time away from tasks such as adding Windows 10 ARM64 support for libwdi... |
|
One day, there will be a low-cost, supported options for developers--I get to work on one--but for now the Snapdragon Development Kit is slated to be released this summer. It won't be on a patch with the indomitable, inexpensive, and community-maintained Raspberry Pi, but Qualcomm will provide and maintain the BSP and is intended to be much less than $1000. |
|
I'd like to chime in here to say please pursue this. Getting a RTL up and running on a Pi 4 running Windows 10 ARM64 would be a real boost to a lot of people. I have two projects stalled just for lack of a driver I can install for RTL-SDR's. I'd be happy to help do any testing needed when it gets that far. Or is there some other way to get an RTL driver loaded, maybe through pnputil? |
|
How many people really care about Windows on ARM? I am an ARM fan. My main computer is the Mac Mini M1 (based on ARM64). My main Linux machine is the Raspberry Pi 400 (along with some other ARM boards). But I do not really care for Windows on ARM. My work and home Windows laptops are running on Intel CPU (AMD CPU is also okay). Ref: libusb does support ARM32/ARM64 on Windows with VS, but not MinGW. |
|
Hi Xiaofan, I think more people care about Windows on ARM than you give them credit for. Having worked on the effort to make Windows run on the Pi 4, I can tell you that there is genuine interest for an cheap yet powerful enough ARM64 platform that can run modern Windows, as buying into the intel/AMD framework can still be prohibitive for a lot of people for varied reasons. And the thing is, Microsoft is perfectly placed to compete with Apple on ARM at a junction where apple will never ever go: cheap platforms. In other words, if Microsoft embraced cheap ARM64 platforms like the Pi 4 (which we know can run Windows 10, or even 11, with "good enough" performance for every day tasks like web surfing, e-mail, document editing and so on), they would probably find a vast sway of users to follow them there, that aren't going to find their match with other options, and especially not Apple MX or Linux on ARM. And that's because the existing Windows ecosystem, with a market dominance that means that if you're looking for an application chances are that you're always going to find at least a Windows version of it, is way too attractive to pass when given the opportunity. Which eventually means that, for a lot of users with limited budget, the choice is between secondhand intel/AMD platforms that run Windows, but that come with the drawbacks of being secondhand, or modern ARM64 platforms that may actually turn out to cheaper than secondhand intel/AMD ones, and run Windows. So, provided that Microsoft are able to read the writing on the wall (which, judging from what's happening with the Pi 4 Windows effort, they sadly don't appear to be able to do. But then again, it wouldn't be Microsoft if they were able to make decisions that actually benefit Windows users in the long run...), you should find that quite a lot of people will eventually care about Windows on ARM, and, even if Microsoft really does make the beginnings of that platform a lot less inviting that it has any rights to be (because, right now, one really has to wonder if Microsoft isn't effectively trying to kill Windows on ARM before it can gain any traction, on account of their complete disregard for all the aspects that effectively contributed to make Windows the dominant OS on x86, such as not getting into some kind of lock in with a specific vendor when it comes to platform development), I am considering that there is more than enough demand to warrant an ARM64 version of Zadig/libwdi. Thus, I am still committed to produce such a version. But, for the foreseeable future, I still have quite a few things that take precedence over that (and the planned release of Windows 11 just added a new major one to that list) so, once again, it'll still have to be quite a few months away... |
|
Thanks for the detailed explanation. Yes it will be good if there are really cheap cheap yet powerful enough ARM64 platform that can run modern Windows. Apparently Raspberry Pi 4 is not yet powerful enough in that aspect. Qualcomm stuff is expensive. And they do not have enough native ARM apps (UWP is very much locked) so that they have to rely on x86/x64 emulation -- that will mean powerful ARM based solution from Qualcomm or similar -- not cheap stuff like Raspberry Pi. So I do not see that happen any time soon. Windows on ARM is pretty much locked, I believe it will be more so in the future with Windows 11. Personally I run Linux on Raspberry Pi 400 and it is really pretty smooth (forget Youtube 1080p for a moment). And you have enough apps. Then Apple has done a great job for Apple Silicon Macs that they run both native ARM apps and x64 apps very well. I use homebrew and within a few month the ARM64 forumlas are mostly working for me already. The main missing thing is Virtual Box but I have alternatives like UTM to run ARM Linux if I want (I do not need now because of Raspberry Pi 400). Anyway, it is just my personal opinion. Sorry for the rant here. And it is great that you are planning to support ARM on Windows with libwdi. |
|
There are A LOT of people out here that care about Windows on ARM. They're just getting discouraged that Microsoft got us this far, and then just seemed to lose interest in finishing it. For a lot of people it's a matter of older software that there is no replacement for. I'm in that boat myself. But guess what, the old XP stuff works pretty darn well on a Pi 4 and Windows 10. You just need to give it the memory to run right, so get the 8GB version, and don't skimp on the SD card size . Booting Linux for the RTL stuff, then an emulator on top of that for the Windows program is not a good solution, but it's what a lot of people are trying to get by. I have no doubt that as soon as an RTL-SDR driver that works on Windows 10 ARM64 on a Raspberry Pi 4 becomes available it'll have thousands of downloads in very short order. Maybe Microsoft is just used to thinking in terms of millions of new downloads a week, while I think in the thousand's, but still... |
|
Good to know that there are "There are A LOT of people out here that care about Windows on ARM". To me it seems the main interests are on Raspberry Pi 4 which somehow gets a license to run Windows on ARM. Raspberry Pi is an exception for Windows on ARM, not the norm. If you read Microsoft document, it is all talking about Qualcomm stuff, which is more expensive than many Intel/AMD laptops. Anyway, Pete is committed to support libwdi on ARM and that is good. For the projects I am involved, at least libusb already supports Windows on ARM. As for libusb-win32, no further development on the project. As for libusbK, I am not so sure if it is worth porting to Windows on ARM or not. Thanks for the changes of Microsoft on Driver signing, we are not going to update libusbk.sys any time soon but we will focus on the support of libusbk.dll which supports WinUSB. |
|
@jkunkee you wrote the following
I do not think this is a real issue for Pete, remember Pete is the original developer of libusb Windows, so he knows the ins and outs of libusb Windows. So there will be no issue for him to host the ARM binary for libusb Windows. Most importantly libwdi/Zadig do not depend on libusb Windows binaries at all (it does not ship with libusb-1.0.dll). You may want to change your blog. |
|
lib usb arm64 dll build made by rusb, great effort is the arm64 version of the lib usb dll |
|
Based on a1ien/rusb#68, vcpkg has already libusb-1.0 Windows ARM binary if you do not want to build the binary by yourself (it is super easy to build libusb-1.0.dll for Windows ARM with VS2019). However, the issue here has nothing to do with that, as libwdi does not depend on libusb-1.0.dll binary at all. |
|
I checked out some Youtube video, now it seems to be much easier to install Windows 10 or Windows 11 onto Raspberry Pi 4 and 400. So I kind of change a bit of my mind in this topic. As for myself, I will not touch Windows on my Raspberry Pi 400 any time soon (Linux is good) and I have no intention to get an 8GB Raspberry Pi 4B. Maybe I will touch Windows 11 on next generation Raspberry Pi 5. |
This is still true with Windows 11 WDK. I just installed Windows 11 WDK. |
|
I believe the way for WinUSB on ARM64 is probably different from ARM32/x86/AMD64, as per the following test and other WinUSB related tests (total 10 WinUSB related tests). On the other hand, ARM32 is mostly dead. ARM64 is probably the future for Windows on ARM. |
|
As Jon mentioned:
So the way to approach WinUSB on ARM64 should be to use a Unfortunately, it's because the However, this whole thing may be rendered completely moot by Windows 11, since Microsoft is no longer trusting certificates that are installed in Trusted Publishers for the signing of driver packages, and that is what we have been relying on to be able to install drivers on Windows 7 up to Windows 10 without having to ask users to enable test signing. Which means that Zadig cannot be used on regular Windows 11 to install WinUSB (fails with As such, unless there's a way to make libwdi/Zadig relevant for Window 11, I'm not sure spending time adding ARM64 support is that great of an investment... |
Hmm, where do you get this info that "Microsoft is no longer trusting certificates that are installed in Trusted Publishers for the signing of driver packages"? For Windows 10, Microsoft also says that Attestation Signing (you need an EV certificate to create an account to sign in the Microsoft Partner Center Developer Dashboard and then get the signed driver package) or HLK (aka WHQL) is needed but in reality Zadig just works. |
|
I believe I now have a version of the library that can take care of ARM64 driver installation. Note that, since I'm not planning to build native ARM64 versions of the library or the examples at this stage (mostly because I don't want to multiply the versions of Zadig people need to download), this requires x86 or x64 emulation on the ARM64 platform, which shouldn't be an issue if using Windows 10 or Windows 11. Oh, and for the underlying platform detection to work, you must use Windows 10 1511 or later. Earlier platforms are not supported. And only the MSVC build can support ARM64, since MinGW is unable to compile the required ARM64 installer binary. I have tested WinUSB driver installation through the x86 build of Zadig on a Raspberry Pi 4 platform running Windows 11 21H2, and was able to both get the WinUSB driver successfully installed for an XBox Controller, and confirmed that it behaved as expected by invoking libusb's Obviously, I could use some more testing, so if you want to download the latest |
* Requires x86 emulation on the ARM64 platform since we are not compiling native libraries or examples (only the internal installer is native). * Only WinUSB and USBSer drivers are supported. * Addresses #155.
It does not have the libusbK.sys for Arm64 windows, If possible can the same be provided aswell? |
No, there will be no libusbK.sys for ARM/ARM64. Rather the focus is to support WinUSB. Please help to try out the libusbK Windows ARM64 test binary mentioned above to see if that works or not. Thanks. |
|
With the release of libwdi 1.5.0 and Zadig 2.8, both of which should support ARM64 driver installation, I'm going to consider this issue closed. |
|
As per #288, Virtual Machine using Parallel under macOS Apple Silicon (ARM64) does not seem to work. The workaround of using test signing is probably not a good way to go. Let's see if there are other reports as well to see if Zadig 2.8 works well for Windows on ARM64 or not. |
|
There is another report that Zadig does not work on Windows on ARM64 here. @CartBlanche |
|
Have you tried to use Zadig 2.8 on your Windows on ARM64 machine? Does it work? Thanks. |
|
I'm using Zadig - Version 2.8 (Build 782) My device details are: Edition Windows 11 Pro @mcuee I see that Zadig has an option for logging (currently set to Debug), but where are the logs kept? |
Ah, yours is another virtual installation like #288 and it seems currently Zadig does not support virtual installation. Are you using Parallel Desktop 18 for Mac? If you have set up the log verbosity option to Debug, then the debug log will appear in the textbox once you run the driver installation. Please post the full debug log here, you should get something similar to the following. |
Nope it does not, tested it on WinARM v10 & v11. 😕 |
Thanks for the confirmation. What is the HW you are testing with? |
|
Hello all Just wanted to second that the version 2.8 does not install the drivers on my Windows DevKit 2023 - log provided below. Am I right understanding that test signing needs to be on? The message |
Yes, the issue is that on some Windows 11 platforms, Microsoft appears to no longer honour their official documentation that states that one should be able to sign a driver package and get the signing certificate into Trusted Publishers and is therefore producing the message:
(Note that, since the above mentions Trusted Root rather than Trusted Publishers, and in case you wonder if that could be the issue, libwdi does installs a driver package's self signing certificate in both Trusted Publishers and Trusted Root, so it's not an issue of installing it to the wrong store, even more so as I'm pretty sure I tried all the stores when I last saw this issue). This is a problem we had seen pop out in some Windows 11 Insider releases (#242) and which we also discussed on osr.com. At the time, it was only manifesting in the pre-release version of Windows 11 x64 but that, thankfully, was not carried out into the actual release of Windows 11 x64. Unfortunately, it appears that these changes were not innocuous and that Microsoft carried them into the Windows 11 ARM64 release. Unfortunately, we do not know if this is due to a "new" security option that could be altered (e.g. Group Policy) and if so, which one, or if it something set in stone. Another possibility is that the certificate we create is missing some new property that Microsoft wants to see before it considers it as a valid Trusted Publishers certificate. Especially, they seem to have changed the wording of their trusted-publishers-certificate-store article linked above to heavily imply that only Authenticode certificates will work, so I have to wonder if Microsoft hasn't added additional validation checks to determine whether a certificate is really an Authenticode one or not, whatever that means... I'm obviously planning to investigate this further, but I don't know when I'll be able to do so. |
|
Thanks for the report. Since you are using the Windows DevKit 2023, are you running an insider version of Windows 11 on ARM64 or a release version? What is the version number? Any chance you can run a release version if you are currently running an insider version? Thanks. |
|
Hey, thanks for getting back to me, I'm running a release version - Windows 11 Enterprise 22621.1555 22H2 It is interesting what @pbatard said about the driver signature enforcement misbehaving on ARM64 - it is something I might be able to help with, I will reach out to a ARM64 DL internally and see if anyone can weigh in on the matter. Perhaps it would be a good idea to reopen the issue? |
Appreciated, thanks.
I may do that, but the core of this specific issue was to have a version of libwdi that was compatible with Windows on ARM64 (i.e. that could provide a WinUSB driver that one could actually install on ARM64 one way or another), which I consider sorted, even if the current solution is obviously less than satisfactory for Windows 11 users. Plus this issue has a bit too many comments, and was originally about Windows 10, not Windows 11, and I kind of expect Windows 10 not to have that issue on ARM64... So I will probably open a new issue specifically for the current topic once I see a bit clearer... |
I think that is a good idea. |
|
Happy to tack this onto a new issue, and sorry if this is a non-sequitur: It may be worth keeping an eye out for DeviceGuard (WDAC, I think). At least some ARM64 devices ship with it enabled, and IIRC I've had to mess with it to load a test-signed hypervisor with Secure Boot disabled before. (I don't know if it should cause issues with trusting additional Trusted Publisher certs for a WinUSB INF, but it wouldn't shock me...) In particular, I'd be looing for a non-zero value in |
|
I think I may have found a workaround. You need to disable Driver Signature Enforcement in Windows. To do that, you need to reboot your Windows into a Safe Mode (Start Menu, right click on power button, and hold SHIFT while clicking on Restart). While in the safe mode, go into Troubleshoot / Advanced Options / Startup Settings. Click Restart, select option 7 (Disable Driver Signature Enforcement). Once the Windows reboots, install Zadig drivers as usual. I'm running Win 11 Pro in Parallels on Mac and it works well. My setup:
|
Wow! This is great news. I've been researching this for weeks. I tried this method you shared and everything seems fine! Thank you very much for sharing and thank you very much to everyone here who worked on this. I can now remove my old laptop with Intel processor from my desk! :) Thanks again David :) my setup; Macbook Pro M1 (Apple Silicon) 2020 |
|
Please take note what @phantomski77 proposed is well-known and not a real work-around. It is not recommended for typical end users. Please refer to the comments here by libwdi developer (Pete). |
I would offer a different perspective @mcuee if I may.
I completely understand that for someone running Windows 11 on their only computer as a primary OS this might be a significant threat and a step too far. That in my opinion should still not be kept secret, but advertised as an option with the appropriate warnings and pitfalls. Keep in mind, that for someone it literally is the only option. But please also consider that there's non-zero amount of users who have no emotional connection to their Windows instance and run it purely as a side note in their sandboxed VM, which sole purpose is to provide a place to run a software that's restricted to that particular niche. And don't let me start about the whole arm64 saga. It's been more than a decade. It's time to adapt (not directed at you and not your fault) |
Thanks so much for this. I wasn't able to find an answer and so would differ that this isn't well known and is a workaroud. By its very nature is safe "for technically minded people", the option is very hidden in Windows and on my Surface Pro X even had to enter my Bitlocker Recovery Key to get to this option. I'm pleased to add you only need to do this "to install the driver" and "if you change the physical device". Once installed it continues to work even with Driver Signature Enforcement re-enabled. Thanks again. |
Thank you. |
I am well aware this is probably pushing it, but I have an ARM64 based Windows 10 Pro machine sitting in front of me currently and am attempting to get it working with an RTL-SDR.
Zadig runs fine and doesn't seem to have any issues, unfortunately though when I select the usual "Bulk-In, Interface (Interface 0)" and hit Install Driver for "WinUSB", I get a "The driver installation failed" error.
I have attached the log.
I have no idea if the drivers etc will work on this machine, will admit I am no major expert in Windows 10 Pro on ARM64 (simply a machine that has been handed to me for this project), but am intrigued if it would be possible to make it work.
Finally, the machine itself is an HP Envy x2.
The text was updated successfully, but these errors were encountered: