I noticed an update prompt in Logic 2 yesterday and went ahead and updated the software.
Ever since doing this the software has felt quite unstable (regular lockups, requiring me to close the app and kill the task in task manager). I also encountered (only one time so far) a momentary UI behavior where the rendering logic did not show new capture data until I stopped the capture; creating a new tab happened to resolve this, this was quite odd and I am not really sure I can explain the behavior clearly at this point, but it was quite jarring how different the UI was behaving.
One thing that might help me to determine if the software locked up or not is for Saleae to improve the feedback on when it is releasing memory (not sure the feasibility of this though); I have noticed that after some relatively long periods of time (multiple minutes), the software does unfreeze, but other times I get the impression it is permanently stuck. To be clear some UI elements continue to function; but the capture logic is basically not functional in this state.
Seeing that there is no mention of this version on the forum, is there any chance this was an accidental release? Anyone else having new problems with this version?
I wanted to try downgrading to v2.4.44 but I seem unable to do this (I uninstalled v2.4.45 and reinstalled v2.4.44), the software installs but it never connects to the MSO.
- EDIT: Nevermind this. The second time I was able to get the old version working again, and I can confirm the issue I am primarily reporting here has gone away (after the downgrade).
Hi @Jonathan,
Thanks for reporting this! This is the second report I’ve seen of issues with the latest release.
(Also you’re right, I forgot to post it to the forum. The release went out very late Friday night, and I forgot to do it this week. I’m traveling right now but will post the details later this week)
Logic 2.4.45 is a huge change over 2.4.44, mostly under the hood. Quite a bit of the data processing pipeline was touched. The other report we’ve seen so far was specific to mouse zoom interactions. However, we haven’t been able to reproduce any issues like these on any of our test machines or devices so far.
We would love to get your help reproducing this so we can find the issue and fix it.
Can you provide some more details?
- Please send us your machine ID. If you have analytics and error reports enabled, we should be able to check logs for a number of possible issues: Getting your Machine ID | Saleae
- What operating system are you using?
- How much memory is installed in your system? What is the software’s memory limit set to? (this is now located in the recording settings sidebar, under the analog sample rate settings) the default is 3 GB.
- Are you using any protocol decoders? if so, which ones?
- How many channels of analog & digital do you have enabled?
The first thing I’d like to establish is if the problem is consistent or only present during high stress. The lock ups you described are consistent with runaway memory usage. When the OS starts paging memory as it’s being recorded from the device, This can bring the software (and sometimes the rest of the system) to a grinding halt. We recently made significant changes to the memory management system (and we’re working on more) and it’s possible we added a bug that’s causing this. I’d like to replicate your use case as closely as possible, to give the highest chance of reproducing the issues.
Your help with this is greatly appreciated - looking forward to getting a fix shipped.
Hi Mark,
Thanks for the prompt response. Here is my attempt at giving you the details you asked for and some additional information.
-
{“ReleaseChannel”:“stable”,“Branch”:“HEAD”,“Commit”:“acf66edc3e5a63e939ffb92ceaec48d8dc14165c”,“Version”:“2.4.45”,“AutomationVersion”:“1.0.0”,“MachineID”:“8f9be6fc-0e57-4b86-8358-32e303af10aa”,“PID”:28740,“LaunchId”:“6bccebfe-d80b-493f-a73a-655bb4558744”,“Architecture”:“x64”}
-
Windows 11 Pro. Addition details copied from System–>About:
Edition Windows 11 Pro
Version 25H2
Installed on 8/13/2025
OS build 26200.8875
Experience Windows Feature Experience Pack 1000.26100.334.0
-
I have 64GB of DDR5. I have set the memory limits to 3GB and 16GB in some cases; I have played around with setting it very high in the 32GB range in the past, this is certainly when I start to see some long delays when closing a tab in the software.
-
I have been using a mix (3) of custom LLA implementations all of which I am planning on making public once I have time to finalize some of the lingering details. In any case I have reproduced this issue in the Saleae SPI analyzer with the 4 analog channels enabled with all 4 set to digital decode. General process:
- Launch logic-software
- Enable the 4 analog channels and activate digital decode mode. Set buffer to 3GB if not already.
- Ensure no LLA/HLA is loaded.
- Start the capture in FreeRun (I have triggered this in other modes too).
- Stop the capture, repeat step 4&5 multiple times to confirm no issue with capture logic.
- Load the SPI analyzer and assign to the 4 digital channels.
- Start the capture.
- In my case there is a high likelihood that it does not capture at this point. It may capture successfully once, twice, maybe even three times, but each time it gets less and less likely. I do not think I have been able to take 5 captures in a row in this build.
-
I have been playing around with this. More recently I have been using the analog inputs in digital mode with the QSPI-Flash plugin (just looking at the SPI-based instructions at startup of an application I am working on), but I have been using this with for quite some time using 2 MSO pods (for the full 6-pin QSPI interface, CLK, NCS, MOSI, MISO, SIO3, SIO4)
For what it is worth, when the application encounters this and I try to restart it (without forcefully ending the Logic software in task manager), I am generally presented with:
In this case, I see the MSO’s LED remain lit green (seemingly indefinitely). Normally some time after closing the software, the MSO deinitializes, which I assume is normal behavior.
I may be able to get a screen recording showing some of this behavior is you think that might help; when I have more free time.
Thanks @Jonathan, all those details help a lot. I’ve already found 19+ internal error reports from your machine ID that indicate the data processing backend is stalling right after starting the SPI analyzer. Unfortunately there is some missing data that would help us nail this down in more detail. I’m traveling at the moment but will be able to dig into this more soon.
Could you share a bit of detail about that SPI interface you’re recording? The clock speed / bits per second could help us try and reproduce the amount of stress its under very accurately.
Another quick test for you to run. Can you repeat what you’re doing but with all the inputs of the device floating / disconnected? That will put zero stress on the protocol analyzer system. If the issues go away completely, that will help us narrow down the problem dramatically.
Oh, and that “Device Connection Failure” is likely happening because the old instance hasn’t exited and still has an exclusive handle to the device. In the short term, you will still need to manually kill any stuck instances of Logic.exe.
Another quick test for you to run. Can you repeat what you’re doing but with all the inputs of the device floating / disconnected? That will put zero stress on the protocol analyzer system. If the issues go away completely, that will help us narrow down the problem dramatically.
I am able to reproduce the problem without any SPI communication activity. As another datapoint, I also reproduced it using the Saleae I2C analyzer (again, nothing is connected and data lines remain constant).
In other cases, I have been working with SPI comms running around 10MHz, 40MHz, and 100MHz. Most of my testing right now is not pushing a lot of data around, mostly a short burst of data and then idle. The main case when I get a lot of data captured would be when I am capturing SPI LCD communications using one of my custom LLAs for decoding LCD communications for a couple common display controllers. But based on what I am seeing right now, it seems the issue is unrelated to demanding work. If I do not have an analyzer loaded the software seems stable to me (maybe not testing thoroughly enough to say for certain right now, but is a significantly different behavior once a LLA is loaded).
One more data point, I have not tested this long enough yet, but I do not believe this issue is present on my Logic Pro 16.
Completely unrelated note: I just want to say I appreciate the small details on improving the UI like the new “maximize data table” button, goes a long way when you have a lot of analyzers loaded. A another feature (related to having a lot of analyzers loaded) I personally would love to see to that part of the UI have a sort of toggle button to activate/deactivate an LLA/HLA without needing to delete and lose the configuration. This can help users manage memory usage a bit more (It was not until I got an MSO that I was driven to upgrade from 32GB to 64GB. Timing could have not been worse with the memory market 
)
Hi @Jonathan,
Now that I’m back at the office I think I’ve been able to reproduce your troubles. I have no idea how we didn’t catch this before the release went out. I’ll investigate and let you know once we have a a fix for you.
Hi @Jonathan,
We just shipped a fix! Logic 2.4.46
Let us know if you have any more problems with it.
1 Like
It definitely seems to behaving much better.
I did seem to get stuck in a really interesting spot. Below you can see the trigger way off to the left and kind of strange info on the time-scale bar. While in this state it seems to crash on next capture. It also seems my software is stuck booting into this mode every time I relaunched the software.
So as another measure I uninstalled and I looked around my AppData (Roaming) and cleared that out too (not sure if this would help in any way for this problem) to try to get back to a fresh install. I made a backup of this data in case it is hard to reproduce.
So far I have not encountered the issue again. I will keep you posted if I do.
I have encountered the timescale trigger position bug several more times. Here is what I have found:
-
Deleting the roaming data does resolve the issue (I think it is specifically the “config.json” file which allows the application to recover from this).
-
Looking at the config.json file with a diff before (faulty state) and after (new config/working app) I see this entry stick out (while the offset is large the effective time, when taking into account the timescale, does not seem blatantly wrong).
-
I seem to be navigating the capture when I notice this happen, but I am not really sure yet what leads up to it. I did notice one time the trigger way off to the right and I recentered via “J” (sometimes I have noticed this stops working, not sure if this is related or a symptom).
-
When in this mode it usually results in the software crashing a moment after capturing new data; though one time I think it still continued to capture, just the trigger position was way off.
EDIT: In another instance I simply set the “triggerOffsetSeconds” to 0, and this appeared to resolve the issue.
Thanks @Jonathan,
I can reproduce it here too. It turns out it’s not a regression either, this bug has been with us for a little while. I hope to have a fix soon.
You are correct on all counts. the easiest way to reproduce it is to start in free-run capture mode, then after you have some data, switch to trigger mode, and press record. Then, press J. you will see the timeline jump to -1Gs before it crashes.
There are several layers to this bug, but the most obvious one is how we are migrating the viewstate offset when we switch from free-run to trigger mode. In this case we should probably just reset the offset to zero and have the trigger line centered for you.
1 Like
I can confirm your suggested process reproduces it for me as well.
