Error on Win 11 running BMP App

[gerritv]

I need to run blackmagic-bmda on my Win 11 pc to host a connection to my probe from WSL2. When I run the .exe from the repository I get:
`Black Magic Debug App v2.0.0
for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 C3F9ADF0 Black Magic Debug
Black Magic Probe (ST-Link/v2) v1.10.2-dirty
Error opening registry key SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02&0002\Device Parameters, got error 00000002: The system cannot find the file specified.

prefix:
Error opening registry key SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00&0000\Device Parameters, got error 00000002: The system cannot find the file specified.

Unexpected problems finding the device!`

How can i get past this? I tried suing Zadig to swap the driver to WinUSB with same result.

[dragonmux]

We are aware of this issue.. this is something specific to W11 and needs further diagnostic. It's not to do with the driver attached to the probe (which should already be WinUSB on the interfaces that matter - if you switched to WinUSB for the serial interfaces, that will have broken things, so please put those back to usbser.sys). Rather, it's to do with the HKLM enumeration tree getting reorganised in some way in W11 in a way that broke the code that has to dive the registry.

Please use regedit.exe and take a look in the HKLM hive at SYSTEM\CurrentControlSet\Enum\USB w/ the probe plugged in and let us know what you see at that level in the tree please. The key it's trying to look up at that point is the instance ID to then find the instance in the main USB device tree to figure out what the serial interface presented is named as.

[gerritv]

it shows: (i could uninstall the device and reconnect to get fresh data if needed)

[dragonmux]

It's the values under the highlighted key (on the right hand side) that we need - specifically the ParentIdPrefix key; and then under the &MI_02 key, we need to know if the instance ID (ParentIdPrefix) appears and if it does if it has a Device Parameters subkey w/ PortName value and where.

What appears in Device Manager isn't particularly useful at this moment in part because it relates extremely thinly to what's going on in the enumeration tree

[gerritv]

here you are:

and

[dragonmux]

The root device' Device Parameters aren't of interest here (second screenshot) - it's the ones in the &MI_02 tree - though at least that confirms the instance ID didn't wander and cause problems.

We're aiming to see though if the VID_1D50&PID_6018&MI_02 tree has an entry for the instance ID (and what it's suffixed with), and then if /that/ has a Device Parameters subtree w/ a PortName value

[gerritv]

[gerritv]

may as well give you MI_00 as well. (I'll be offline for a while)

[dragonmux]

Ok, so.. something is going wrong in how the ParentIdPrefix value is being handled, resulting in the string building failing in an exciting way.. SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02&0002\Device Parameters should actually be SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\6&29896882&0&0002\Device Parameters which then actually exists and can be read for PortName.

The question now becomes why despite asking for a RRF_RT_REG_SZ which appears to be encoded as a readable string with no non-printing characters.. we're getting back something that causes formatting to scrub a \ and the entire rest of the instance ID string.. suggesting non-printable characters being present (we'll noodle on this when more with it now we have the information needed to dry run things locally)

[gerritv]

Using RRF_RT_ANY instead of RRF_RT_REG_SZ makes things happy again. Is that taking the easy way out?

[dragonmux]

Unfortunately not really - what this does is makes it so Windows can return any kind of value back to us (including integers, binary data, and unexpanded environment variable references), which we'd then need to somehow handle safely before presuming that what we were getting was a string and doing string things with it. That's precisely why we have the type restriction applied there.

We're glad that gets things working for you in the moment - our job now becomes figuring out what exact type of value is getting returned, why, and how to make it work with the type restriction in play so we can do the read safely.

[dragonmux]

One of the thoughts we've had of exploring is forcing those registry manipulations to their W variants, and doing the string formatting with wsprintf() in case this is because of some stupid that's happened with conversion inside the RegGetValueA() implementation.. concerning though, given the registry value in question is type REG_SZ, which should mean a simple string and thus RRF_RT_REG_SZ.

[gerritv]

ok, I'll be patient. I appreciate you looking at it.
if you need me to try something let me know