Windows 10 on ARM64 support

[gbaman]

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.

Zadig 2.3.701
Windows 10 32 bit (Build 17134)
ini file 'zadig.ini' not found - default parameters will be used
default driver set to 'WinUSB'
2 devices found.
libwdi:debug [wdi_create_list] Hardware ID: USB\VID_0BDA&PID_2838&REV_0100&MI_00
libwdi:debug [wdi_create_list] Compatible ID: USB\Class_ff&SubClass_ff&Prot_ff
libwdi:debug [wdi_create_list] Driverless USB device (0): USB\VID_0BDA&PID_2838&MI_00\6&38A180A5&0&0000
libwdi:debug [wdi_create_list] Device description: 'Bulk-In, Interface (Interface 0)'
libwdi:debug [wdi_create_list] Hardware ID: USB\VID_0BDA&PID_2838&REV_0100&MI_01
libwdi:debug [wdi_create_list] Compatible ID: USB\Class_ff&SubClass_ff&Prot_ff
libwdi:debug [wdi_create_list] Driverless USB device (2): USB\VID_0BDA&PID_2838&MI_01\6&38A180A5&0&0001
libwdi:debug [wdi_create_list] Device description: 'Bulk-In, Interface (Interface 1)'
Checking for Zadig updates...

Checking release channel...

Using inf name: Bulk-In_Interface_(Interface_0).inf
Successfully extracted driver files.
Installing driver. Please wait...
Updates: Unable to acces version data

libwdi:info [extract_binaries] successfully extracted driver files to C:\Users\HAB\usb_driver
libwdi:info [wdi_prepare_driver] successfully created 'C:\Users\HAB\usb_driver\Bulk-In_Interface_(Interface_0).inf'
libwdi:info [wdi_prepare_driver] Creating and self-signing a .cat file...
libwdi:debug [AddFileHash] 'wdfcoinstaller01011.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\HAB\usb_driver\amd64\wdfcoinstaller01011.dll'
libwdi:debug [AddFileHash] 'winusbcoinstaller2.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\HAB\usb_driver\amd64\winusbcoinstaller2.dll'
libwdi:debug [AddFileHash] 'bulk-in_interface_(interface_0).inf': INF type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\HAB\usb_driver\bulk-in_interface_(interface_0).inf'
libwdi:debug [AddFileHash] 'wdfcoinstaller01011.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\HAB\usb_driver\x86\wdfcoinstaller01011.dll'
libwdi:debug [AddFileHash] 'winusbcoinstaller2.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\HAB\usb_driver\x86\winusbcoinstaller2.dll'
libwdi:info [CreateCat] successfully created file 'C:\Users\HAB\usb_driver\Bulk-In_Interface_(Interface_0).cat'
libwdi:info [RemoveCertFromStore] deleted existing certificate 'CN=USB\VID_0BDA&PID_2838&MI_00 (libwdi autogenerated)' from 'Root' store
libwdi:info [RemoveCertFromStore] deleted existing certificate 'CN=USB\VID_0BDA&PID_2838&MI_00 (libwdi autogenerated)' from 'TrustedPublisher' store
libwdi:debug [CreateSelfSignedCert] set Enhanced Key Usage, URL and CPS
libwdi:debug [CreateSelfSignedCert] created new key container
libwdi:debug [CreateSelfSignedCert] generated new keypair
libwdi:info [CreateSelfSignedCert] created new self-signed certificate 'CN=USB\VID_0BDA&PID_2838&MI_00 (libwdi autogenerated)'
libwdi:debug [SelfSignFile] successfully created certificate 'CN=USB\VID_0BDA&PID_2838&MI_00 (libwdi autogenerated)'
libwdi:info [SelfSignFile] added certificate 'CN=USB\VID_0BDA&PID_2838&MI_00 (libwdi autogenerated)' to 'Root' and 'TrustedPublisher' stores
libwdi:info [SelfSignFile] successfully signed file 'C:\Users\HAB\usb_driver\Bulk-In_Interface_(Interface_0).cat'
libwdi:info [SelfSignFile] successfully deleted private key
libwdi:debug [wdi_install_driver] using progress bar mode
libwdi:debug [installer process] got parameter Bulk-In_Interface_(Interface_0).inf
libwdi:debug [process_message] got request for device_id
libwdi:debug [installer process] got device_id: 'USB\VID_0BDA&PID_2838&MI_00\6&38A180A5&0&0000'
libwdi:debug [process_message] got request for hardware_id
libwdi:debug [installer process] got hardware_id: 'USB\VID_0BDA&PID_2838&REV_0100&MI_00'
libwdi:debug [installer process] got user_sid: 'S-1-5-21-4036245373-3405510498-1736261573-1003'
libwdi:debug [installer process] using syslog 'C:\WINDOWS\inf\setupapi.dev.log'
libwdi:debug [installer process] syslog reader thread started
libwdi:debug [installer process] successfully disabled the system restore point creation setting
libwdi:debug [process_message] switching timeout to infinite
libwdi:debug [installer process] Installing driver for USB\VID_0BDA&PID_2838&REV_0100&MI_00 - please wait...
libwdi:debug [process_message] switching timeout back to finite
libwdi:debug [installer process] attempted to use a 32 bit installer on a 64 bit machine
libwdi:debug [process_message] installer process completed
Driver Installation: FAILED (Attempted to use a 32 bit installer on a 64 bit machine)
2 devices found.
libwdi:debug [wdi_create_list] Hardware ID: USB\VID_0BDA&PID_2838&REV_0100&MI_00
libwdi:debug [wdi_create_list] Compatible ID: USB\Class_ff&SubClass_ff&Prot_ff
libwdi:debug [wdi_create_list] Driverless USB device (0): USB\VID_0BDA&PID_2838&MI_00\6&38A180A5&0&0000
libwdi:debug [wdi_create_list] Device description: 'Bulk-In, Interface (Interface 0)'
libwdi:debug [wdi_create_list] Hardware ID: USB\VID_0BDA&PID_2838&REV_0100&MI_01
libwdi:debug [wdi_create_list] Compatible ID: USB\Class_ff&SubClass_ff&Prot_ff
libwdi:debug [wdi_create_list] Driverless USB device (2): USB\VID_0BDA&PID_2838&MI_01\6&38A180A5&0&0001
libwdi:debug [wdi_create_list] Device description: 'Bulk-In, Interface (Interface 1)'

[pbatard]

Zadig runs fine

Wait, are you running the x86 version of Zadig that is published at https://zadig.akeo.ie?
That will not work, first of all because it will run on ARM64 in x86 emulation mode (which I doubt Microsoft allows installing ARM64 drivers from) and second, because there are no ARM64 embedded in Zadig in the first place, so even if it "worked", it wouldn't be able to find the files it requires for ARM64.

Also:

Windows 10 32 bit (Build 17134)
(...)
Driver Installation: FAILED (Attempted to use a 32 bit installer on a 64 bit machine)

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...

[gbaman]

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.
If you have somewhere rough you could point me to on where to start, I don't mind taking a glance at recompiling it. No guarantees though... :)

[pbatard]

If you have somewhere rough you could point me to on where to start

Oh boy...

• Well, first you'll have to find if and where MS provides ARM64 versions of their CoInstaller DLLs.
• Once you have that, you'll need to edit this mess to handle ARM64 (and while you're at it you may also want to add ARM).
• You'll also want to edit this and this to add ARM64 support.
• Then you'll need to edit the MS project files so lbwdi/Zadig can be compiled for ARM64 (and while you're at it you may also want to add ARM - btw this might help you.
• There's also some more stuff that will be needed, such as updating the check for update in Zadig so that the ARM64 version doesn't try to download the x86 version, or reporting the arch on startup, but I've already done that in Rufus, so you don't really have to do it as I should be able to reuse that code.
• Last but not least you will need to test, test and test again to make sure that your changes work on ARM64 machines! Adding the code is 20% of the work. Testing is 80%!

[vielmetti]

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.

[jkunkee]

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.)

[pbatard]

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 arm64 directory). And what's more, even for ARM, there's no winusbcoinstaller2.dll provided, which means we can't support that platform either.

At the very least, libwdi requires the following 2 DLLs to be provided able to support an architecture:

• WdfCoInstaller01011.dll
• winusbcoinstaller2.dll

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 IsWow64Process2(), as this seems more useful than IsWow64Process() indeed.

[jkunkee]

That's what my system shows too; I'll see what I can do.

[jkunkee]

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. :/

[pbatard]

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 [USB_Install.CoInstallers] section from the winusb.inf template... I'm hoping we can filter these things out with [USB_Install.CoInstallers.x86] and [USB_Install.CoInstallers.amd64] but this will require some testing. And of course I'll need to add conditional logic on whether to search for the coinstallers or not depending on the platform.

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.

[vielmetti]

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

[sidd-kishan]

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.

[pbatard]

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...