UI crashes because of Windows fatal exception: code 0x8001010d

I was recently trying to open the Joulescope UI from the command-line like this:

>"C:\Program Files (x86)\Joulescope\joulescope.exe" 20210814_030430_0001.jls

and found that 5 out of 11 attempts will open the UI successfully and display the graphs. The other 6 will show a white window and crash the UI.

JLS File, crash log, screenshot found here:

Windows fatal exception: code 0x8001010d

Thread 0x00002438 (most recent call first):
  File "joulescope\usb\winusb\win32_device_notify.py", line 119 in _run_window
  File "threading.py", line 892 in run
  File "threading.py", line 954 in _bootstrap_inner
  File "threading.py", line 912 in _bootstrap

Thread 0x00000af0 (most recent call first):
  File "joulescope\data_recorder.py", line 897 in _reduction_handler_v2
  File "joulescWindows fatal exception: oaccess violationp

e\data_recorder.py", line 869 in _reduction_tlv
  File "joulescope\data_recorder.py", line 934 in get_reduction
  File "joulescope\data_recorder.py", line 1051 in data_get
  File "joulescope_ui\recording_viewer_device_v1.py", line 121 in _update
  File "joulescope_ui\recording_viewer_device_v1.py", line 327 in run
  File "threading.py", line 892 in run
  File "threading.py", line 954 in _bootstrap_inner
  File "threading.py", line 912 in _bootstrap

Thread 0x00001370 (most recent call first):
  File "multiprocessing\connection.py", line 816 in _exhaustive_wait
  File "multiprocessing\connection.py", line 884 in wait
  File "multiprocessing\connection.py", line 335 in _poll
  File "multiprocessing\connection.py", line 262 in poll
  File "multiprocessing\queues.py", line 113 in get
  File "joulescope_ui\logging_util.py", line 181 in _listener_run
  File "threading.py", line 892 in run
  File "threading.py", line 954 in _bootstrap_inner
  File "threading.py", line 912 in _bootstrap

Current thread 0x000022dc (most recent call first):
  File "joulescope_ui\main.py", line 1942 in run
  File "joulescope_ui\entry_points\ui.py", line 50 in on_cmd
  File "joulescope\entry_points\runner.py", line 105 in run
  File "joulescope_ui\__main__.py", line 41 in <module>

Hi @andrewhh and welcome to the Joulescope forum!

Thanks for the detailed information. I download the JLS file, and of course, it works great (no crashes in 20 tries with Joulescope UI 0.9.7) on the first machine I tried. I noticed that 0.9.5 fixed a race condition when starting the UI with the JLS file argument. It looks like we did not entirely fix the issue.

I created issue #132.

I think that the device discovery is conflicting with opening the JLS file. If you unplug your Joulescope and start the Joulescope UI with the JLS file argument, does the UI always start without crashing?

I tried launching joulescope.exe with the JLS argument with the Joulescope unplugged and it succeeded 6/11 times. The other times it crashed.

The log files are here: iCloud

Sometimes the Windows Fatal Error is in the middle of the log

Thanks for the additional log files, @andrewhh ! joulescope_20210816_163855_2448.log was especially strange with two different crash stack traces.

I tried to duplicate the issue on two different machines across several different SSDs, HDDs, and network drives with no success yet. I have a few more machines that I will try…

I can share control of the PC via your TeamViewer account if you have one

Thank you for the offer @andrewhh . Ideally, I would like to recreate the issue on a local machine so that we can investigate and know that we fixed it. Let me see what we can do, but I may take you up on the offer. Thanks!

This is the exact computer it is running on. I hope it’s not too underpowered: https://www.amazon.com/BMAX-Computer-i3-5005U-Processor-Expandable/dp/B08VDMW5T2/ref=sr_1_33?dchild=1&keywords=mini+pc&qid=1628121655&sr=8-33

The i3-5005U will not be winning any performance awards, but it should still run the Joulescope UI. We will consider slower processing causing race conditions while looking for the issue.

I’ve been looking at the stack traces and code. I haven’t found any issue yet, but I do have a question.

If you launch the Joulescope UI normally without a Joulescope connected and then do FileOpen, do you see the same crashes on this machine? If it works the first time, you can select Devicedisable and then repeat.

I tried this procedure 3 times with the Joulescope connected and 3 times with the Joulescope not connected. Crash only on attempt 4. Successful open 5/6 other times.

Logs: icloud.com/ iclouddrive/0TPxYZ-o0CNtwaH2a4igFNRnQ#Joulescope_crash_2021-08-17

Discourse is forbidding me from posting iCloud links without spaces

I got the log files. You should also be able to post the links normally going forward since I marked as not spam.

I took a look, and every single log shows an access violation. It’s strange, but most of the access violations seem to occur while simultaneously:

  1. Attempting to read the JLS file, but at different points in the code.
  2. Attempting to check for Joulescope UI updates.

Not sure it’s going to help, but you could turn off the automatic update check. FilePreferencesGeneralupdate_check and click to unselect it.

I tried disabling “update check” and Joulescope GUI succeeds in opening 6/11 times

Video: icloud.com/ iclouddrive/0mgrAoanr1_x4pXGTNckc6c2Q#Joulescope_crash_after_disabling_update_check

Thanks for the video. Finding segfaults in python is painful, and I am not making much progress. I suspect something about how numpy is processing the JLS file. The code is likely not holding onto a reference that is used slightly later. These types of issues take a long time to track down.

How about a different approach? The JLS v1 file format you are currently using is on the way out. While we will continue to support it for a long while, the JLS v2 format is a huge improvement and is already being used by a few customers. The Joulescope UI already supports viewing the JLS v2 file, so you should be able to use it to display your captured data.

I created a new capture_jls_v2 example. Can you capture your data like this to the JLS v2 file format?

I have no preference for JLS v1 or v2 so I will try v2. Does it work with “trigger.py” yet? I will try the capture_jls_v2.py

I tried running capture_jls_v2.py for 90s and found that the JLS file is twice as large. 1.4GB instead of 0.7GB. But I don’t care.

Opening the file is much faster and the Joulescope GUI succeeded 11/11 times.

Can trigger.py be updated to use the new JLS file format?

Hi @andrewhh - Great to hear that the JLS v2 file format works. Yes, recording voltage and current will be 2x the size, at least until we add compression. The JLS v1 format stores the raw 14-bit samples (32-bits @ 2 MHz), at least for full-rate data. The v2 format always stores float32 values for current and voltage.

I refactored the JlsWriter into pyjoulescope. You will need to upgrade:

pip3 install -U pyjls joulescope

I updated the trigger example to store JLS v2 by default.

python bin\trigger.py --start duration --end duration --record

You can then get info about these files:

pyjls info --verbose <filename>

Does this integrate into your automated test setup?

Thanks for updating trigger.py! Yes it fits now into my automated setup. I changed trigger.py to disable all output and only output JSON so my script can read the output more easily.

{'start_time(samples)': '2000000', 'start_time(iso)': '2021-08-18T23:46:04.974448', 'end_time(samples)': '182000000', 'end_time(iso)': '2021-08-18T23:47:34.967916', 'current_mean(A)': '0.00696091', 'current_min(A)': '-7.13831e-05', 'current_max(A)': '0.0605409', 'voltage_mean(V)': '3.88184', 'voltage_min(V)': '3.84703', 'voltage_max(V)': '3.89697', 'power_mean(W)': '0.0269445', 'power_min(W)': '-0.000277368', 'power_max(W)': '0.233452', 'charge(C)': '0.626482', 'charge(Ah)': '0.000174023', 'energy(J)': '2.42501', 'energy(Wh)': '0.000673613'}
1 Like

We did address this issue in 0.9.11, but I am not sure if it fixes the problem on your machine. If the problem continues, please let me know!