@TimVisma:

I'm hopeful we may be on to something here.

The second stack trace here points towards something NCrunch shouldn't really be doing with this frequency, and it's a prime suspect. The good news is that I can redesign this area of code to more or less eliminate the potential concern.

The first stack trace is more complicated. This particular routine is only supposed to run when the DPI scaling changes for the rendered component. DPI scaling changes are pretty unusual, so seeing this as a suspect makes me wonder if something is not right with the way the scaling is being reported. Do you still have the logs for this? If so, can you search for trace lines like this:

NCrunch tool window *** scaling was changed scaling is ***

If the scaling is adapting more often than it should be, this should be showing up in the trace logs.


@DerAlbert:

If it's a hard crash, a simpler option might be to check the trace logs for your Rider installation. Go to Help->Show Log In Explorer. Check through the files most recently updated to see if there's anything towards the bottom that could suggest a reason for the crash.

To get a debugger on the top level Rider process requires using Intellij, which might be overkill if you don't have it installed. Let's see what's in the logs first and if necessary I can walk you through hooking a debugger onto one of the background processes if it looks like they're involved.

Ok, I have an update on these issues.

First I'd like to disclose that currently I cannot myself reproduce any issue reported in this thread, so all actions I'm taking here are entirely speculative. Presently I am aware of 3 issues here:
- Potential performance issue related to DPI sync that may have the ability to cause IDE freezes if DPI routines aren't functioning as expected
- Potential performance issue in a routine that synchronises NCrunch with open editor windows in Rider, which may be able to freeze the IDE if certain O/S routines are performing poorly (will likely be worse if a lot of windows are open on the desktop)
- Crash issue triggered by compressing the Tests Window into a very small corner of the IDE

There is potential for another issue that causes freezing. I suspect this because prior to the stack traces reported by Tim/JB, I have myself experienced a freeze issue that didn't implicate NCrunch in the stack traces. This may be due to misanalysis on my part (I'm still learning my way around Rider diagnostics). Right now I have no actionable info on this problem so I'm treating it as theoretical.

For the first two issues, I've redesigned the code involved in a way that I hope makes the problems effectively impossible to surface.

For the third issue (crash one), I've done a dive through the logs provided by Albert and engaged in some new (unfruitful) attempts to reproduce it myself. While doing this, I uncovered a number of internal exception issues related to over-compressing the Tests Window on the 5.19 test builds. I've resolved these issues, but I don't think they are implicated in the crash. The logs from Albert show the crash originating from Wormhole internals inside Rider without NCrunch code on the stack. NCrunch uses Wormhole (an internal Rider component) to stream the tool windows from its backend process. It's somewhat of a black box to me and I don't have the capability to debug it. If the build below makes no difference, I think that this problem is best submitted to JB, as they will likely have the ability to further diagnose it.

Anyway, here is a build with the above fixes. Please try it out and let me know if it helps with the freezing.

NCrunch_Console_5.19.0.3.msi
NCrunch_Console_5.19.0.3.zip
NCrunch_GridNodeServer_5.19.0.3.msi
NCrunch_GridNodeServer_5.19.0.3.zip
NCrunch_LicenseServer_5.19.0.3.zip
NCrunch_Rider_5.19.0.3.7z
NCrunch_Rider_5.19.0.3.zip
NCrunch_VS2010_5.19.0.3.msi
NCrunch_VS2010_5.19.0.3.zip
NCrunch_VS2012_5.19.0.3.msi
NCrunch_VS2012_5.19.0.3.zip
NCrunch_VS2013_5.19.0.3.msi
NCrunch_VS2013_5.19.0.3.zip
NCrunch_VS2015_5.19.0.3.msi
NCrunch_VS2015_5.19.0.3.msi.7z
NCrunch_VS2015_5.19.0.3.zip
NCrunch_VS2017_5.19.0.3.msi
NCrunch_VS2017_5.19.0.3.msi.7z
NCrunch_VS2017_5.19.0.3.zip
NCrunch_VS2019_5.19.0.3.msi
NCrunch_VS2019_5.19.0.3.msi.7z
NCrunch_VS2019_5.19.0.3.zip
NCrunch_VS2022_5.19.0.3.msi
NCrunch_VS2022_5.19.0.3.msi.7z
NCrunch_VS2022_5.19.0.3.zip
NCrunch_VS2026_5.19.0.3.msi
NCrunch_VS2026_5.19.0.3.msi.7z
NCrunch_VS2026_5.19.0.3.zip

You're welcome :) I think there's a likelihood the problem is still there though.



Given the number of scaling related issues I see these days, this is a notable data point. I'm interested to see if it still works for you on Wednesday.

I have a theory about this. v5.19.0.2 included a DPI related fix for the trace output causing crashes when the scrollbar ate all the horizontal space on the screen due to platform bugs. One of the angles of this fix was to prevent the trace output from rendering if it was made too small, since the rendering for it doesn't like trying to size around such a small space. I think this simultaneously fixed your issue. It makes sense as my testing was assuming you were running this build (referenced earlier in this thread), so I wasn't able to reproduce.

So I think we're all good and fixed here. The stack trace in the Rider log was a red herring, since the front-side process would have been ghosted as soon as the backend crashed.



Not yet. I'm probably going to throw the switch on this soon, probably just after pushing 5.19. So it will likely be 5.20.

Works also fine on different Monitors (32" 4K) with different scaling (125%)

In my case of minimizing no freezing in current Rider 2025.2, with 5.19.0.3

Have sometimes other Freezes, which i don't know if NCrunch is involved. But this is "just" a couple of seconds.