nrfutil device list command fails

[Ronald Hoogenboom]

I just freshly (Nov 25, 2024) installed the nrfutil 'core' exe and the nrfutil device command.

I try to list my nrf devices (a nrf52840 dongle is connected and another nrf52840 through jlink), but the command fails:

$ nrfutil device list
thread '<unnamed>' panicked at src\serialport\module\src\windows.rs:118:55:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at core\src\panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
0: 0x7ffcc9b646a1 - nrfdl_plugin_identifier
1: 0x7ffcc9b760d9 - nrfdl_plugin_identifier
2: 0x7ffcc9b62de7 - nrfdl_plugin_identifier
3: 0x7ffcc9b65ea9 - nrfdl_plugin_identifier
4: 0x7ffcc9b65a2c - nrfdl_plugin_identifier
5: 0x7ffcc9b66722 - nrfdl_plugin_identifier
6: 0x7ffcc9b665bf - nrfdl_plugin_identifier
7: 0x7ffcc9b64def - nrfdl_plugin_identifier
8: 0x7ffcc9b66206 - nrfdl_plugin_identifier
9: 0x7ffcc9b84e6d - nrfdl_plugin_identifier
10: 0x7ffcc9b84f13 - nrfdl_plugin_identifier
11: 0x7ffcc9b84fab - nrfdl_plugin_identifier
12: 0x7ffcc9a6dcab - nrfdl_plugin_enumerate
13: 0x7ffcf43b1060 - <unknown>
14: 0x7ffcf43b4d38 - is_exception_typeof
15: 0x7ffd491149c6 - RtlCaptureContext2
16: 0x7ffcc9a6d946 - nrfdl_plugin_enumerate
17: 0x7ffd0f02933a - <unknown>
18: 0x7ffd0f0268bd - <unknown>
19: 0x7ffd0f023e86 - <unknown>
20: 0x7ffd0f023b6f - <unknown>
21: 0x7ffd0f004553 - <unknown>
22: 0x7ffd0f024822 - <unknown>
23: 0x7ffd0f027e03 - <unknown>
24: 0x7ffd0f004e64 - <unknown>
25: 0x7ffd0f003918 - <unknown>
26: 0x7ffd1da229a9 - Concurrency::details::_Schedule_chore
27: 0x7ffd490d287a - RtlHashUnicodeString
28: 0x7ffd490a5e46 - RtlClearThreadWorkOnBehalfTicket
29: 0x7ffd46ee257d - BaseThreadInitThunk
30: 0x7ffd490caf08 - RtlUserThreadStart
thread caused non-unwinding panic. aborting.
Error: Subprocess C:\Users\ronaldh\.nrfutil\bin\nrfutil-device.exe failed with unexpected exit code Some(-1073740791)

Setting the RUST_BACKTRACE env-var produces the extra:

Stack backtrace:
0: git_odb_object_data
1: git_odb_object_data
2: git_midx_writer_new
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: git_odb_object_data
8: <unknown>
9: git_midx_writer_new
10: BaseThreadInitThunk
11: RtlUserThreadStart

Unplugging either or both connected nrf devices from USB doesn't change the behavior.

What gives?

NOTE: programming the nrf52840 dongle using the programmer tool in "nrf connect desktop" is just fine.

[dejans]

Hi,

Can you provide more information about your environment?

I just freshly (Nov 25, 2024) installed the nrfutil 'core' exe and the nrfutil device command.

Which "nrfutil" and "nrfutil device" versions do you use?

Where did you install nrfutil from?

$ nrfutil device list
thread '<unnamed>' panicked at src\serialport\module\src\windows.rs:118:55:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at core\src\panicking.rs:221:5:
panic in a function that cannot unwind

Is this recent problem? Did you have this issue before?

Best regards,
Dejan

[Ronald Hoogenboom]

As I said I just installed it today from the internet, so yes it is a recent problem and no I didn't have this issue before.

$ nrfutil.exe --version
nrfutil 7.12.0 (39003c9 2024-06-10)
commit-hash: 39003c9d0e5d946af0f417cfadf4ac55a6d03c19
commit-date: 2024-06-10
host: x86_64-pc-windows-msvc
build-timestamp: 2024-06-10T15:56:55.227746900Z
classification: nrf-external

$ nrfutil.exe device --version
nrfutil-device 2.7.6 (040a257 2024-11-15)
commit-hash: 040a25785d0b79da111e042ef002f04cf8547e46
commit-date: 2024-11-15
host: x86_64-pc-windows-msvc
build-timestamp: 2024-11-15T10:11:07.009117500Z
classification: nrf-external

Detected SEGGER J-Link version: JLink_V7.94i

[dejans]

Hi,

Allmoz said:

If it's helpful, I was having the same issue for some days, disconnected a st-link-v2 programmer I also had plugged in into the USB, fixed itself and I have not been able to replicate it anymore.

Is it correct that the issue is not present anymore on your end?

Best regards,
Dejan

[Allmoz]

It's correct, and I don't know how to trigger it again nor if there is other drivers/devices/conditions that would make it happen.

[Ronald Hoogenboom]

NOTE: I don't have any other programmers plugged in the USB than the 2 devices I described.

[dejans]

Hi,

The fix is expected to be available during next week. I will provide an update here when this happens.

Best regards,
Dejan

[Ronald Hoogenboom]

Can you indicate what was the cause of the problem? Just for information to others that may have hit the same situation and search this forum (and for me to satisfy my curiosity).

[dejans]

Hi,

I will ask internally about the cause of the problem and provide an update.

Best regards,
Dejan

[dejans]

Hi,

The fix is released as part of nrfutil device v2.7.8. The problem was that "Friendly Name" in Windows registry for connected device did not include COM name and the code did not handle this gracefully.

Best regards,
Dejan

[Ronald Hoogenboom]

OK, now the behavior is:

$ nrfutil device list
thread 'main' panicked at src\list.rs:63:30:
comName did not have a string value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Subprocess C:\Users\ronaldh\.nrfutil\bin\nrfutil-device.exe failed with unexpected exit code Some(101)

Although there is now no unhandled exception, it still doesn't help me much...

Friendly names are for human consumption. I think it is a bad idea to parse a friendly name to discover the COMx. There MUST be a better way (even in windows)!

[Ronald Hoogenboom]

I will add a few screenshots that could potentially help solving this.

There are so many 'FriendlyName's in the registry, I wasn't able to figure out which FriendlyName the nrfutil-device program finds to determine the COM name. The COM3 is my samsung phone (Copilot: The ssudmdm.sys file is a driver associated with Samsung mobile devices.) and the COM6 is the BLE sniffer.

The USB serial device (com6) is the nrf52840 dongle now programmed as BLE sniffer, so it doesn't support DFU anymore. The USB DFU is some other device (maybe also my samsung), not the nrf dongle nor the jlink.

[Ronald Hoogenboom]

OK, I guess I figured out what you're doing.
You are traversing the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB to find 'FriendlyName's for USB devices.

I see indeed that for my 2 COM ports, there is one that has the COMx in parentheses in the FriendlyName (the BLE sniffer) and one that hasn't (the samsung phone). You are at the mercy of the USB device driver vendor it that is available or not.
However, in the subkey 'Device Parameters' ALWAYS has reliably the PortName key which has the COMx name.

I would advise to use that instead of parsing the FriendlyName to try and find the PortName, which may or may not be available.

Your're welcome!