RSP1A Crash at 8 MHz Bandwidth

[RadioSDR1]

I'm observing SDRC crashing when using 8 MHz bandwidth. This has been a long running problem I've never reported because I seldom use more than 2 MHz of bandwidth and the crashing at 8 MHz of bandwidth is at random times.

Though there may be a loose correlation between a crash and switching frequencies whereas staying parked on one frequency will take longer to crash than if frequency hopping. Maybe. But there have been other times where it can go awhile and not crash regardless of whether changing frequencies or not.

When SDRC crashes, memory and processor is not maxed out but it is somewhat high. Processor as reported by SDRC is in the 20%-40% range and memory is in the 1 to 2 GB range. In Task Manager, total CPU for the machine is typically around 70% and memory around 70% as well and I've watched the Task Manager as it crashes and neither memory or processor spike above those numbers.

Not sure if this is really a bug or perhaps some resource on my older machine is being tapped out that in turn makes SDRC mad. Maybe I have some setting somewhere in SDRC that is either causing or contributing to the problem.

[Max]

I'm observing SDRC crashing when using 8 MHz bandwidth. This has been a long running problem I've never reported because I seldom use more than 2 MHz of bandwidth and the crashing at 8 MHz of bandwidth is at random times.

Just checking that you are running the latest version of SDRC? v3.3 Build 3236 (Feb 5th 2024)

Max

[RadioSDR1]

Yep. Build 3236. This has been a problem on earlier betas too. Not exactly sure when I first noticed this. Many months ago, at least. And whenever a new release or beta comes out, I always install it. Also, I have not tested this on other bandwidths though I suspect 10 MHz or 7 MHz would probably get crabby.

Is there any kind of logging that would indicate what SDRC might be unhappy about at the time of crash like this?

[Max]

Yep. Build 3236. This has been a problem on earlier betas too. Not exactly sure when I first noticed this. Many months ago, at least. And whenever a new release or beta comes out, I always install it. Also, I have not tested this on other bandwidths though I suspect 10 MHz or 7 MHz would probably get crabby.

Is there any kind of logging that would indicate what SDRC might be unhappy about at the time of crash like this?

Just tried to provoke this with my RSP2Pro. Cannot get it to fall over even with many receivers (more than 10) and constant frequency changes for couple of minutes.

When it crashes, how does it crash? So what I mean is, does it just freeze or does it crash with a message that it is doing a crash dump?
https://www.sdr-radio.com/crash-dump

I guess you could try examining the log file but whether it would show anything of use up to the crash I'm not sure:
https://www.sdr-radio.com/logfile

One slight worry is your CPU usage. It seems somewhat high. On my machine I have Nvidia GPU operating in CUDA mode. With RSP2Pro at 10MHz bandwidth and waterfall running at speed 40 (default), I'm seeing a CPU reported at 0% on SDRC, GPU between about 6% and 17%.

Max

[KA1GJU]

How about sharing some PC information as to the system's OS, hardware , etc.
From the ribbon bar across the top, click on "Tools", then "DirectX Diagnostics", "Save All Information", and then attach the text file "DxDiag.txt". That will save you lots of typing!

73 Kriss KA1GJU

[RadioSDR1]

Max & Kriss:

Attached is the DxDiag.txt with machine info.

I did a little investigating. So when SDRC crashes, it says "Please Wait" and when this happens I kill SDRC. Apparently it is trying to create a crash dump. I recreated the problem and let the process complete but it takes a really long time, like 20 minutes. In comparison, if I create a crash dump in the Task Manager, that is only few seconds or so.

FYI, the size of the uncompressed .dmp file created during an actual crash is about 2.4 GB whereas the uncompressed .dmp file created from Task Manager is around 615 MB. Even though the actual crash dump file is larger than the manually created one, it is only about 4 times as a large but takes a really really long time to make. I don't know if this behavior is normal so thought I'd mention it.

Also attached is the output of the WinDBG on the .dmp file SDRC makes during a crash. I am no expert using WinDBG nor interpreting its output. I presume the attached output is sort of a limited summary of the captured data. The long and the short of it is that it seems that "SDR Console.exe" caused an access violation with "SDRSourceSDRPlayV3.dll".

My sense is that if this is a bug with SDRC, there would likely be more complaints. And Max you report not being able to recreate it. If it is not a bug, then perhaps something on my machine that SDRC depends on is at fault. If so, if any ideas of what I can hunt for would be appreciated.

[Max]

Max & Kriss:

Attached is the DxDiag.txt with machine info.

The long and the short of it is that it seems that "SDR Console.exe" caused an access violation with "SDRSourceSDRPlayV3.dll".

My sense is that if this is a bug with SDRC, there would likely be more complaints. And Max you report not being able to recreate it. If it is not a bug, then perhaps something on my machine that SDRC depends on is at fault. If so, if any ideas of what I can hunt for would be appreciated.

Afraid this is well past my diagnostic level. If there's a crash dump then really only Simon can help analyse. As you say, if a common issue then would expect it to have been reported by others, especially as the RSP1A has been around for quite a while now.

Because of where the problem is reported, perhaps the first thing I would try if it were me is remove the RSP1A radio definition from SDR Console. Complete uninstall of the SDR Play API. Download and install the latest release API from SDR Play. Then re-add the RSP1A to SDR Console. See if that helps. None of the above would (I don't think?) remove any stored information except possibly remembered gain settings in SDR Console on the RSP, and maybe not even those.

Maybe try that first and see how it goes?

One last thing. If you look on Windows at "Installed Apps" screen in settings, what version of the SDR Play API are you reporting. I don't really use my RSP these days so my API is reporting an old version 3.11:
https://www.sdrplay.com/api/

So I will uninstall 3.11 and re-install 3.14 and have another go at provoking the issue with my RSP2Pro.

Max

[Max]

One last thing. If you look on Windows at "Installed Apps" screen in settings, what version of the SDR Play API are you reporting. I don't really use my RSP these days so my API is reporting an old version 3.11:
https://www.sdrplay.com/api/

So I will uninstall 3.11 and re-install 3.14 and have another go at provoking the issue with my RSP2Pro.

Max

Removed Radio Definition from from SDRC. Uninstalled 3.11. Downloaded and installed 3.14. Re-added Definition. Still not able to provoke a crash after longish run and huge number of frequency changes and 21 receivers. All while reporting 0% CPU (in SDRC) and about 17% GPU. Still worth uninstalling and reinstalling on your machine though I reckon.

Max

[RadioSDR1]

The API is 3.14. I remember awhile back an issue with crashes on an earlier API version but that was at any bandwidth. Though Max interesting your CPU is so low. I do not have GPU video processing given the type of video card in my laptop. I wonder if you could recreate running everything on the CPU. Also I'm on an AMD processor so not sure if the fact it is not Intel plays a role somehow.