Guys -
Why doesn’t Saleae install on Microsoft surface? It installs the pre-requisite Windows C++ redristributable, but then withdraws the install. ALL of my other apps installed fine, and the surface has an x86 to ARM converter in it. So - what gives here. I NEED SALEAE IN THE LAB BADLY.
By the way, I have 4 Saleaes and the company has over 10 Saleaes with surfaces in the lab.
@davidcbassett471 Unfortunately we don’t officially support Windows on ARM processors yet, and we won’t be able to get to this for some time. Though, given you have over 10 Saleae Logic devices in your lab, I certainly understand this is not acceptable in your case!
Assuming that Windows is able to emulate our x86_64 application, it’s possible that the main issue is getting an ARM driver installed for our device.
In parallel, I’ve added a comment for you in the feature request post we are tracking for this below to ensure we track your need for this.
I’ll be meeting with the rest of the team here later this week on this topic. We’ll follow up with you on our recommendations. Apologies for the trouble in the meantime…
Hi Tim,
Thanks a ton for the fast reply. Microsoft has done a decent emulator layer so all the x86 based .exe apps I have install correctly. So, there should be no need to compile code for ARM. None of the other apps do. This is a windows 11 based tablet.and all the other apps are strictly windows apps. So, it should install fine. Adam Knobelsdorff (he also has 3 personal Saleaes of his own) gave me some advice to install the redistributable separately and see if there might be a decent log file output which can help you.
I would be willing to install any test code you might want to check, but I think the surface should be some priority simply because it acts fully like a PC, and one which can be doing lab work.
Thanks Tim. I love my Saleaes to death and have 3 of them running on 3 PCs debugging 3 boards at the same time - pretty cool stuff actually. I’ll be getting Honeywell to order some more early next year.
db
Hello,
There are 3 things blocking the Logic software from running on Windows on ARM at the moment:
I recently bought a new Surface laptop to test this ourselves. I have been able to verify a workaround for the first 2 issues, but I haven’t had the time to finish working on the driver part.
Below are instructions to work around all of these issues. I haven’t tested the driver part yet though.
We use a Microsoft provided driver, WinUSB. We currently only distribute the x86_64 version of this, but Microsoft provides instructions for manually associating the WinUSB driver with a specific device, so theoretically, you do not need to use the driver distributed by us.
The process takes 12 steps and unfortunately I haven’t tested it yet.
If you are willing to try the manual installation method, you can find the instructions here:
Specifically, you will want to follow all the steps in the section “Installing WinUSB by specifying the system-provided device class”.
That includes the first steps 1-7, then the second steps 1-5.
There are a few changes however.
In the second set of instructions, step 2 asks you to generate a GUID. In this case, you must use the GUID for the specific model of unit you have purchased, as it is specified in the Saleae *.inf file included with our driver. Relevant GUIDs:
Logic 8
“{03C61D2D-8A38-4FD3-9E60-1BCAA5FA28C1}”
Logic Pro 8
“{DDB1D63F-0ECF-4E86-94E7-ADB4C765E352}”
Logic Pro 16
“{DDB1D63F-0ECF-4E86-94E7-ADB4C765E353}”
Again, this needs to match the device you purchased exactly. Using the GUID from the wrong device type will cause the software to crash.
Step 3 requires you to find the registry key based on the VID & PID, which is the USB identification of the device. The VID is specific to Saleae and the PID is specific to which model of device you have. I think you will need the HEX version of these two numbers.
Logic 8:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_21A9&PID_1004
Logic Pro 8:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_21A9&PID_1005
Logic Pro 16:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_21A9&PID_1006
That should do the trick. You will only need to perform these steps for the device you are trying to use, you can ignore the GUID and registry keys above for our other products.
In addition, since the installer will not finish installing, you will need a “stand alone” copy of our software. This is just a zip file that includes our software.
https://logic2-dev.saleae.com/app/Logic-2.4.14-windows-x64-master-a59be960f.zip
Note, the software requires the “Visual C++ Redistributable for Visual Studio 2019” to be installed. Normally our installer handles that for you. You will need the x86_64 version. You can either download it from Microsoft, or you can grab a copy from us here:
https://www.dropbox.com/scl/fi/lqjgopgnmojd3tswm7wll/vc_redist.x64.exe?rlkey=b8chz4houy7wzilqsejcxnvp8&dl=0
I haven’t attempted this yet, my plan is to focus on getting an ARM copy of the driver signed, however I can’t provide an timeline for that. If you attempt this, please let us know!
I don’t have a surface, but regarding WinUSB driver remapping – does the Zadig utility work on Win/ARM64?
I’ve used this for Windows (x86/64) applications to switch from default USB drivers assigned by Windows (HID/CDC/etc.) to use WinUSB and/or libusb, but no idea if this will work on ARM.
[Edit:]
According to this issue on libwdi (part of Zadig):
… it looks like there is a chance (at least on Windows 10):
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.
Apparently, Windows 11 for ARM64 may have changed the driver package signing rules, preventing Zadig/libwdi from working on Windows 11 (but allegedly as of Zadig 2.8 will work on Windows 10 for ARM64). Note: If you have your driver package signed through Microsoft’s chain of trust (vs. just locally trusted certificate), then it apparently isn’t a problem.
I think Zadig basically gives you a GUI to automate registering/remapping USB devices (VID:PIDs) & corresponding drivers w/o manually poking registry keys and/or editing the *.inf files yourself. It doesn’t sign the driver binaries, it just (re)maps a device to an existing driver like WinUSB (or libusb, or Windows’ built-in USB HID/CDC/etc.)
Anyway, hope this info might help with the workaround until a ‘properly signed’ installation/driver is available.
Hi Mark,
I have never in my life seen a company so fantastic with customers as Saleae, and I will praise you guys until I drop. It is why I have pushed Saleae in Honeywell and will continue until they are in every engineers hands. When I got here there were zero. Now we have over 10, and I got the India team to buy a couple. I have 3 myself and my buddy Adam Knobelsdorff has 3 of his own also.
I made a mistake with the original 16 and blew it. I called and said I will pay to get this fixed. What I got was a new one overnighted to me. Are you kidding me??? I was hooked for life.
Here is what I would love to see - a 4 channel pro version for around $500 or even $399. I can’t tell you the number of times I do I2C or SPI compared to needing all 15 channels. Just a thought.
Keep up the fantastic work, Mark. I hate the word because people use it for McDonalds fries, but you guys are truly awesome.
db
Hi mark,
Sorry. Forgot to mention I will try this, but it will probably take this weekend because I actually have 3 Saleae screens of 15 channels I need to debug.3 Saleae 16 pros, 3 boards with jumper wires, and 3 debug code I changed.
db
I’m still working on this nights and weekends. I have the driver signed, but I’m still not able to install it, due to issues with the digital signature. In the past, we’ve never submitted our drivers to the Windows Hardware Developer Center Dashboard portal before, and I wasn’t aware that it was required. It looks like it is required for machines with SecureBoot enabled, but I don’t think we’ve seen any reports of problems with our existing drivers on these machines. I’ve disabled SecureBoot on my Surface Laptop, but it still won’t install. (Note, do not disable secure boot on your machine without first verifying that you can access your bit-locker recovery code!)
Anyway I’ll keep pushing this forward in my spare time. I did not expect it to be this difficult.
Hi Mark,
The one quality I have found in my 71 years and 50 at high tech is persistence does pay. High tech humbles me daily. Thank you for all your efforts. If I didn’t think the surface could be a great lab tool, then I would have said drop it already. But, it has a very high speed input (thunderbolt/USB C 3.1, and can do up to 32G RAM to buffer. So, it can be a great Saleae tool going forward. The thing is light, small, and slender so i can carry it on trips and debug remotely. Thanks again for your effort.
db
I’ve spent the last two months working through getting our Kernel mode USB driver (last touched 2007) through certification. Most of the first month was sorting out the Extended Validation certificate we needed ($US1000) and that our current code signing cert wasn’t up to the task.
With the plethora of nasty failure modes and paucity of useful help on the internet this task is vastly more frustrating than it should be. I feel your pain! Not sure I can help, but if you need a teddy bear to bounce ideas off feel free to send me an email.
Bottom line: getting drivers signed is difficult and frustrating!
I am by no means an expert, but the way I understand the Zadig utility works (referenced above) is to add its own root certificate to the “Trusted Publisher” store, and uses that to sign the driver package.
This is obviously not the preferred method for distributing a signed driver package as a commercial tool, but can be a nice work around for users wanting to install 3rd party software without $1000 certificates nor disabling secure boot / requiring signed drivers.
As mentioned before, I don’t have Windows 10 for ARM (just on x86/64), but the Zadig tool has worked for effectively side-loading USB drivers and remapping from
For example, here’s what it shows on my Win10/64-bit (x86/64) PC:
… so it looks like the WinUSB driver packaged w/ Saleae Logic is a little older than the latest version of WinUSB available in Windows 10 [Version 10.0.19045.4894]?
Anyway, it is pretty simple to remap, just make sure Options > List All Devices is checked:
… and then find/select the Logic device in the drop-down list.
You can then Upgrade/Replace driver (as desired), depending on what you want to do. Unfortunately, I’m not sure if any of this works for ARM based Windows, but as noted earlier – it is supposed to work now (after Zadig 2.8). You do need to have Administrator rights for Zadig to work, as it needs the admin permissions to install a new root certificate, locally.
Note: some of the forum discussions about Zadig had issues, but allegedly might be resolved. Also, some of this was for Windows 10 IoT (on a Raspberry Pi?) vs. a Windows Surface. There was plenty of discussion on issues with Microsoft changing policies for Windows on ARM (vs. Windows on x86/64) as far as device driver signing (and even driver package signing), so it does seem like they’ve made it more painful for 3rd party device driver/bundling on the ARM platforms.
As noted above I’ve been working with a Kernel mode driver and the rules are likely different than a WinUSB driver. However “signing the driver” entails both the manufacturer and Microsoft signing the driver files. For our driver extensive testing using Microsoft provided tools is required and is a major pain. It’s likely easier for a WinUSB driver where Microsoft do most of the heavy lifting.
And the driver for all this effort? Well, when was the last time you had a BSOD? Most of my work mates struggle to remember their last BSOD and usually memory failure turns out to be the culprit nowadays. Used to be it was always a badly behaved device driver!
The testing and requirements for Arm are the same as for Intel/AMD for the same version of Windows as far as I can tell. But the testing is getting more rigorous for sure! For consumers is that a bad thing?
The issue at play with ARM vs x86/64 has to do with Microsoft’s policy on signing the driver package (e.g., the install *.inf, etc.) vs. the binaries (*.sys). All most people with Zadig want to do is change the existing (already signed) drivers mapped to a particular device (by VID:PID) as Zadig doesn’t sign any driver binaries (WinUSB and/or libusbK, etc., are signed separately). The issue at hand was ‘self-certified’ device installs & driver remaps – where a local admin can do this with a ‘locally trusted’ root certificate vs. needing chain of trust back to a Microsoft authorized root certificate ($$).
As shown in my screenshot, the Saleae logic is apparently using WinUSB (an existing signed driver provided by Microsoft), but users cannot ‘install’ a new device (register a new VID:PID) to this same driver without having the new device install package signed ‘properly’). My understanding about ARM64 vs. x86/64 is that Microsoft hasn’t allowed user-controlled signatures, even for the install packages (vs. binaries), on Windows 11 for ARM (and might tighten these rules in the future for x86/64 editions).
I totally agree that the signed driver policy has improved stability, but I also think local admins should be able to decide for themselves how to administer their personal ( 
) computer without completely disabling secure boot or disabling all signed driver enforcement. I think Microsoft is taking a stronger ‘admin’ policy on the newer ARM64 platform and trending toward how Apple manages iOS devices: users only get access to approved content vs. self-administrate and/or sideload your own ‘off-menu’ stuff directly instead of the app store. Perhaps if they sell more Surfaces to enterprise (vs. consumer) customers, they may get stronger feedback to allow more ‘self-administered’ controls like x86/64 still does.
Ok, looks like the code signing cert we bought last year is Organization Validated (OV) and not Extended Validation (EV). EV appears to be required for driver signatures on Arm64 Windows 11. Oddly enough, we have no problem with drivers recently signed with our OV cert on x86_64 Windows 10 and Windows 11. The same drivers I just signed on my Arm64 surface, which fail to meet the signature requirements on that platform, install just fine on x86_64 Windows 11.
Anyway, I think we’ll need to acquire a EV certificate, and then submit the drivers to the Windows Hardware Dev Center program for approval, then we should be good to go. Unfortunately I don’t have an eta on this, this is still a background priority for us.
We need to monitor demand for this, so if you’re looking for Arm64 Windows support, please let us know! I’ll keep posting updates here too.
Hi Mark,
Best effort is all you can do and locating the exact problem like you have is comforting in a way. Doesn’t solve my lab problem, but at least I know what the issue is. USB is a monster as I have debugged several boards shipping USB. And Windows certs on top of that are not fun either. I know it is a background task, but maybe you can let us know when this is ready to go? Meantime, I will keep lugging my 6lb laptops around the lab.
At the end here, just want to say I APPRECIATE the work done, Mark. Customer response is everything, and Saleae has shined yet again. Still proud to be a Saleae owner after 12 years (+/-).
db
The EV cert issue was were I was two months ago. It took most of a month to sort out, but largely because it took half that time to figure out that our code signing cert wasn’t an EV cert. The EV cert is required since Windows 10 and Server 2016 regardless of platform. See Driver Signing - Windows drivers | Microsoft Learn. The cert is also needed to sign up for the “Microsoft Partner Center” which notionally gives access to the Developer program where drivers are submitted for signing by Microsoft.
I’m currently stuck trying to work through the process of getting into the Developer Program. Our IT team are working on it, but it’s not a straight forward process!
P -
I can feel the frustration here. I would be too. Thanks a lot for the inputs. probably why I became a HW embedded guy who writes C, VHDL and works on boards. Nothing higher than that. It’s enough to rip your hair out.
db
On the up side, the last time I touched the driver was 17 years ago when we needed to get it signed for 64 bit Vista. This refresh has required about three new lines of code. The frustration has all been fighting a vast void of silence when looking for help having fallen off the happy path. Great documentation for the happy path, almost none when things go sideways.
Our driver is finally signed! Last two “issues”:
Note that the translations are provided by me and are not trivially, or even with reasonable effort, discoverable!
I started the process of getting our existing driver, which has been in public use since 2007, updated for use with Arm Windows computers in June. No code changes were required to make the driver work - just a cross compile for an Arm64 target. Three substantive lines of code have been added to meet modern driver requirements and a number of functions got signature changes to satisfy suggestions for robustness.
Lining up the required certificate for various parts of the process, running the tests across multiple machines and OS versions, and submitting the results has taken most of four months and several weeks of active work to actually get the job done.
Mark: for the pain you are probably suffering through a similar process you have my heart felt sympathy!