Thread viewer empty during debug

[Fefu]

I have two computers where nRF Connect for VSCode behaves differently in the sense that in one computer when I start debug it stops at the first line of the main and I see thread viewer correctly showing the threads and the other computer stops first in the debug at some setup or init script and not in the main. In addition the Thread Viewer is empty.

I use nRF Connect SDK 2.6.1 from c:\ncs\v2.6.1\nrf\west.yml

I did some cleanup by removing VSCode, Segger probe softwares, nRF Connect for Desktop and tools. Then I searched in Windows in %USERPROFILE% and %APPDATA% Local and Roaming anything I could find related to nRF, VSCode, Segger tools. Then I reinstalled and I use a shared profile and the same nRF52840DK board. In the profile is installed nRF Connect for VSCode Extension Pack, which in turn install what is needed.

Despite repeating the same cleanup  and setup, in the home computer it works, and in the workplace doesn't.

I have a feeling that there are some hidden configs which I don't know, therefore is not enough to uninstall and cleanup in  %USERPROFILE% and %APPDATA% .

I really wished to have reliable and repeatable setup. Does anybody where it is saved the configuration regarding where it stops first at the staring point of Debug session?

Where exactly have to be made manual cleanup, to completely reset the developer environment?

[Fefu]

At home I continued to experiment.

I did a comparison of support information and based on that I started to downgrade or destroy the setup at home.

I noticed that at home pc where works, I had in the "tools" the JLink.exe 7.94j. I remember that when I install nRF Connect for VSCode from scratch, it installs JLink.exe 7.94e . Therefore in the workplace's PC I do have only 7.94e installed.

Somehow looks like at home PC I had 7.94e and also 7.94j. Therefore I uninstalled 7.94j and after this I could not debug at all, still was able to flash. (of course always regenerated the build configurations when I did a change). This is somewhat worst than at work.

After I re-installed (back) the 7.94j at home, again nRF Debug it started to work correctly.

I also tried to change the deviceProvider and works with both nrfjprog por nrfutil.

Other difference would be that at home where it works my Home Folder name doesn't have space character. I would be so sad that the username in my workplace computer completely renders useless this plugin. 

Remain that tomorrow I will install also JLink 7.94j just I have at home. And if still doesn't work, remain this folder name with space.

[Fefu]

Now I tried to install JLink 7.94j beside 7.94e as it is my pc at home where threads view is working.

Unfortunately in this PC in my office doesn't work.

I checked the developer logs in extension host and I see this

[error] CodeExpectedError: stackTrace: property 'threadId' is invalid.
    at ZKe.Q (vscode-file://vscode-app/c:/Users/My%20Username/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2154:15459)
    at vscode-file://vscode-app/c:/Users/My%20Username/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2154:15037

I have no idea how it could relate this error to the thread viewer.. maybe not related.

If you know some flags to enable more debug logs, just tell me.

[Fefu]

Some more logs

in exthost.log:

2024-10-09 08:47:24.812 [info] Extension host terminating: renderer closed the MessagePort
2024-10-09 08:47:24.822 [error] An error occurred when deactivating the extension 'nordic-semiconductor.nrf-kconfig':
2024-10-09 08:47:24.823 [error] TypeError: Cannot read properties of undefined (reading 'dispose')
        at Aae (c:\Users\My Username\.vscode\extensions\nordic-semiconductor.nrf-kconfig-2024.9.20\dist\extension.js:231:2662)
        at Object.M5e (c:\Users\My Username\.vscode\extensions\nordic-semiconductor.nrf-kconfig-2024.9.20\dist\extension.js:268:23963)
        at hB.eb (file:///c:/Users/My%20Username/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:118:11727)
        at file:///c:/Users/My%20username/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:118:9877

[Fefu]

Since I couldn't solve the problem of nRF Debug to show threads in my usual user account in the PC at my workspace, I decided to create a new local user account in the same PC and specially I take care to not have space character in user folder name.
I reinstalled nRF Connect for Desktop, the nRF connect command line tools, VSCode. VSCode I enabled cloud sync to pull down my previously installed profiles and extensions. nRF Connect for VSCode extensions are installed in a profile, just to not mix with other extensions.
In this newly created account now nRF Debug and Thread Viewer works correctly. and in the extension host logs I don't have this  "[error] CodeExpectedError: stackTrace: property 'threadId' is invalid." log.  I still have "[error] TypeError: Cannot read properties of undefined (reading 'dispose')" . For the details of the stacktrace, you can search above.

The chances are high that nRF Debug extension, specifically the thread viewer is sensible to spaces in the user folder name. I cannot fully guarantee that this was the exact cause of the problem, since this new user at least is more cleaner. since it was just created.

For positive test, i let someone freshly create a new windows 11 user account with space character in the folder name and do the setup there. If the thread viewer will be empty, than we know the exact cause. If not the space character in the user folder is the real cause, then when somebody else has this issue, at least there is a workaround... just create a new local user account.  Of course I cannot fully support this type of advice, since it is a hassle to setup everything again in the new user account.

[Amanda Hsieh]

Hi, 

I'm trying to follow what happens where, but one thing we can tell is that the user name having space in it (the home folder) does not prevent working on that machine as long as neither the SDK nor the application and build folders are not under the offending home directory. 

-Amanda H.