Problems with nRF Connect for Visual Studio Code: nrfutil and also Generate Support Information

[Burt]

Generate Support Information fails dramatically:

I don't remember how to find the log. How many average users would have the slightest clue!!! Please help.

The other problem is one I have seen others comment on, but the usual solution makes no sense. They say to switch Device Provider from nrfutil to nrfjprog. But why would we do that? nrfutil works fine on the command line

C:\ncs\v2.5.0\nrf\applications\asset_tracker_v2> nrfutil device list
50100377
product J-Link
traits jlink, seggerUsb, usb

6&33aeebb&0&2
ports COM13
traits serialPorts

Found 2 supported device(s)

PS C:\ncs\v2.5.0\nrf\applications\asset_tracker_v2>

So why doesn't work in VS Code? The reason I find this particularly obnoxious is that the documentation states that nrfutil is the default Device Provider. So, it should just work. It is obviously in my Path, too.

Thanks.

Burt

[Burt]

Bummer -- I let the computer sit in sleep for 1.5 hours, came back, and the two problems are back. I did an sfc /scannow and this time there are no errors reported. Also, more files than nrfdl.dll need to be "found": those others must have been cached when I had success copying nrfdl.dll to the other directory. One could add the ~/.vscode/extensions/nordic-semiconductor.nrf-connect-2024.3.25-win32-x64/platform/nrfutil/lib/nrfutil-device directory to the PATH to solve that. So we are sort of back at square 1, needing a hack to get things to work.

Burt

[dejans]

Hi Burt,

Can you provide more information about your system(s) where you encountered the problem with nRF Connect for VS Code extension? Which operating system(s), version of VS Code, and version of nRF Connect for VS Code extension did you use? Did you maybe use pre-release version of the extension?

Burt said:

I have more than one Windows computer here, I am not smart enough to see how that happens automatically on the computer that does not have these problems.

In your tests, was there any Windows computer that did not have these problems?

Can you summarize the differences that you observed when using system installation vs single user installation of VS Code?

Best regards,
Dejan

[Burt]

Hi Dejan,

If you scroll up you will find an instance in which things were temporarily working and I was able to Generate Support Information, but I can also answer your questions here: the computer is running Windows 10Pro; version 22H2 with up-to-date build via Windows Update. I have 3 Windows 10 Pro machines and 1 Windows 11, all with VS Code+nrf Connect and the problem has not occurred on any of the other machines. The versions of VS Code and extension are the current ones; but I have tried the pre-release and also some older versions of the extension. The behavior did not change. Also, I thoroughly uninstalled ALL extensions and ALL VS Code instances, then reinstalled the latest standard versions: no change.

I do believe that there is a temporary caching of dll files that has caused the "now it works, now it does not" phenomenon that has been confusing to me and probably to you while you have read through this ticket. And I think the system installation vs single user installation has been a "red herring": I believe there is no difference between the two installs functioning: that I was probably thrown off the track by the chance that dll's were cached when I tried one vs the other. So maybe it's best to strike system vs single user off the list of likely root causes.

Burt

[Burt]

I did finally figure out the problem, with the help of Mark Russinovich's Process Explorer tool on the Microsoft Store. It is a bug in the extension, triggered by an uncommon situation in a modern Windows installation:

Windows environment variables like PATH are case insensitive. PATH in particular shows up on a fresh Windows installation as Path, and also shows up in most non freshly installed Windows as Path. But every so often, a "power user" might end up with it displaying as PATH rather than Path. Any program that uses the variable must be agnostic to the case that PATH or Path or PaTh (etc) displays. Your extension is not: if it sees Path as it expects, it will modify the Path (or PATH) appropriately to allow nrfutil-device to run. If it sees PATH, for example, it will not modify the PATH (or Path, etc.) properly to allow nrfutil-device.exe to run. That blocks both finding connected devices and also Generate System Information.

You can test this easily by using Edit the system environment variables, selecting the System variable Path,  Edit..., the Edit text. You can change the variable back and forth between Path and PATH very quickly.

I hope you folks will fix the extension in an upcoming release. Thanks, Dejan. By the way, it was probably years ago that my variable name case changed. There were never any problems until the recent one.

Burt

[tesc]

Hi,

Thank you for your extensive debugging and efforts for figuring this out. It is highly appreciated! I have reported the issue to our VS Code extension developers.

By the way, you mention that your Path variable probably changed years ago, and yet from what I understand you did not see any issues until recently. Does this indicate that the issue just recently appeared in the VS Code extension, or are there explanations in your end for why you did not stumble upon the issue previously?

Regards,
Terje