[ISSUE][Win10] Particle CLI : Assertion '(func) != nullptr' failed

[jgu]

• Operating System: Win10

• CPU Architecture: x86-64bit

• Particle CLI Version (run particle version ): 3.1.0

• Contents of your particle directory - ls -a ~/.particle (macOS / linux - bash, etc), get-childitem ~\AppData\Local\particle (windows - powershell)
  

• How was the Particle CLI installed? (standard or advanced?) see docs : Standard

• What terminal / shell are you running the Particle CLI within? (powershell, bash → via Particle Workbench/VSCode )

• What Particle hardware are you using? (Electron)

Suddenly getting an assertion failure when trying to run particle USB commands after the CLI was updated, which is preventing the particle usb * from successfully executing (i.e. particle usb list). I can still flash the device when manually setting DFU mode (either by buttons, or setting COM to 14400).
I’ve followed the steps for clearing the AppData/Local, and running the particle update-cli from the workbench with no successful resolution.
This appears to be similar to what was observed in Linux here (down to the same file/line number):[ERROR] particle cli nodejs thread error , however it is not resolved by removing/reinstalling - which I would guess is a package is possibly missing.

On a side note, when running particle setup, it is able to detect that an Electron is indeed connected.

Particle_FW> particle usb list --verbose
particle usb list --verbose[20300]: c:\ws\src\node_api.cc:1087: Assertion `(func) != nullptr' failed.
 1: 00007FF709A0363F napi_wrap+128063
 2: 00007FF7099A2836 v8::base::CPU::has_sse+35142
 3: 00007FF7099A2B53 v8::base::CPU::has_sse+35939
 4: 00007FF7099C74E5 napi_release_threadsafe_function+181
 5: 00007FFFCA42CFF4 
 6: 00007FFFCA430EA1
 7: 00007FFFCA430BF8
 8: 00007FF7099DC893 node::Stop+72595
 9: 00007FF70A16DBE0 v8::internal::Builtins::builtin_handle+323456
10: 00007FF70A16D127 v8::internal::Builtins::builtin_handle+320711
11: 00007FF70A16D468 v8::internal::Builtins::builtin_handle+321544
12: 00007FF70A16D26E v8::internal::Builtins::builtin_handle+321038
13: 00007FF70A604EDD v8::internal::SetupIsolateDelegate::SetupHeap+546893
14: 00007FF70A589D8C v8::internal::SetupIsolateDelegate::SetupHeap+42748
15: 00007FF70A589D8C v8::internal::SetupIsolateDelegate::SetupHeap+42748
16: 00007FF70A5D7F56 v8::internal::SetupIsolateDelegate::SetupHeap+362694
17: 00007FF70A585443 v8::internal::SetupIsolateDelegate::SetupHeap+23987
18: 00007FF70A6695C0 v8::internal::SetupIsolateDelegate::SetupHeap+958256
19: 00007FF70A589D8C v8::internal::SetupIsolateDelegate::SetupHeap+42748
20: 00007FF70A589D8C v8::internal::SetupIsolateDelegate::SetupHeap+42748
21: 00007FF70A5830BC v8::internal::SetupIsolateDelegate::SetupHeap+14892
22: 00007FF70A5D9392 v8::internal::SetupIsolateDelegate::SetupHeap+367874
23: 00007FF70A5A6F2D v8::internal::SetupIsolateDelegate::SetupHeap+161949
24: 00007FF70A5871AC v8::internal::SetupIsolateDelegate::SetupHeap+31516
25: 00007FF70A0C7CC0 v8::internal::Execution::CallWasm+1536
26: 00007FF70A0C7DB3 v8::internal::Execution::CallWasm+1779
27: 00007FF70A0C8192 v8::internal::Execution::TryCall+354
28: 00007FF70A0AA1A5 v8::internal::MicrotaskQueue::RunMicrotasks+501
29: 00007FF709A1F8D1 node::CallbackScope::~CallbackScope+593
30: 00007FF709A1F6EE node::CallbackScope::~CallbackScope+110
31: 00007FF70996AC9B v8::internal::Scope::locals+30875
32: 00007FF7099CA3D3 node::Start+275
33: 00007FF7098767AC RC4_options+339628
34: 00007FF70A6BBE08 v8::internal::SetupIsolateDelegate::SetupHeap+1296248
35: 00007FFFE4727034 BaseThreadInitThunk+20
36: 00007FFFE5462651 RtlUserThreadStart+33
PS

[rickkas7]

This is just a guess, but it’s possible that you have the very old Windows serial driver installed. It’s not necessary on Windows 10, and can cause issues most notably a BSOD, but maybe this as well?

Removing the old serial driver

[jgu]

So, it seems that this (old driver) may be related, however following the steps doesn’t seem to result in auto-installing the correct driver (and not showing up in Device Manager, just to make life interesting).
COM5 in this case is a RS485/USB converter; it seems that the device is present on COM17.

Side note: removing the converter doesn’t help.

So, I’m kinda bothered by the fact that I couldn’t find that device in the device manager, despite the fact that Zadig still sees it as present, I can use a terminal program with it, and I can still hit it with a python script to put the device in DFU mode.

Changing the view in DeviceManager to View Devices by Connection, they pop up under the USB controller (ACPI x64 based PC > Microsoft ACPI Compliant System > PCI Express Root Complex > Intel USB 3.1 host controller > USB root hub)

And we can note by the icon that they were actually hiding under “Other Devices” in the “View Devices by Type” layout.

Unplugging the Electron, uninstalling those (COM17 and COM29), and re-inserting the Electron:


Seems to use libusbK (dated Sept 2021).
Unplugging the Electron, uninstalling the Electron (and selecting to remove the driver option), waiting for it to complete, then plugging the Electron back in:

Now using libwdi (dated Jun 2012).
Doing it again!

Sticks with the libwdi.

So, according to the link from rickkas7, under Old Serial Drivers, it looks like I should make sure to uninstall all of the Particle devices. Noting that before I didn’t touch the DFU Mode drivers, going ahead and trying to get rid of those.

Result after plugging the device back in:

Out of curiosity at this time, running the particle usb list command:

So the good news is that the error is cleared. But a fairly large question I have at the moment is what driver should actually be used?

[m_m]

our windows installer for the CLI will also install drivers - those instructions are here:

Command Line | Tutorials

[jgu]

Hi m_m; the whole shebang was installed via the windows installer (I’ve been developing working with the Electron since about Oct2020). So it’s a bit odd why it suddenly crapped out - but at least it seems to be working and stable now.
So, if the windows installer worked correctly, what specific driver and version should I be seeing for the device(s)?

[jgu]

Ugh. this is now suddenly popping up with (some) Argons - I’ve been developing on one without any particular driver issues or shenanigans - but now this is rearing its head. Resolution is the same.

[Mikeli]

Wow, wonderful sharing