Remco wrote:Can you confirm whether you're able to crash this every time using the steps to reproduce you've described? (As per my usual luck, I can't get it to happen).
The thread referenced above contains an NCrunch build that restructures how the rendering in the Tests Window trace output works, mitigating issues related to massive CPU consumption when the trace output area gets too small. If you can still reproduce the issue now, I'd be interested to know if this build solves it. If not, I'm probably going to need to ask if you're able to get me a stack trace of the main thread by hooking a debugger onto the NCrunch engine process when the crash happens.
Also, sorry about the version nags. These should go away when the next release goes out (won't be long now).
I just Open Rider with the Solution.
I wait for NCrunch Tests Window saying "No test are queueed for execution".
I resize the Tool Window Area, as small as possible.
I switch the Tool Window and back to NCrunch Tests
Rider freezed
I'm pissed an kill Rider ;/
Uninstalled NCrunch.
Tested this with a different Tool Window (NuGet, which has some "Action") in the Docking Area.
No freeze.
So, i need some advice how to attach the Debugger to NCrunch without Rider.
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.
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.
Did one Test with "minimal" Sizing of the NCrunch Tests Windows (Multiple Times in the same Rider Instance) with 5.19.0.3, and Rider did not freeze.
... having a little tear in my eyes, thank you.
On the other End, I'm sitting on the same computer on different Monitors (until next Wednesday) with different scaling (2x27" 4k, 150% Scaling, one vertical, one horizontal).
And I cannot recall if this problem only happens in the office. I made a note for next Wednesday to check this.
Der-Albert.com wrote:
Did one Test with "minimal" Sizing of the NCrunch Tests Windows (Multiple Times in the same Rider Instance) with 5.19.0.3, and Rider did not freeze.
... having a little tear in my eyes, thank you.
You're welcome :) I think there's a likelihood the problem is still there though.
Der-Albert.com wrote:
On the other End, I'm sitting on the same computer on different Monitors (until next Wednesday) with different scaling (2x27" 4k, 150% Scaling, one vertical, one horizontal).
And I cannot recall if this problem only happens in the office. I made a note for next Wednesday to check this.
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.
Decided not to wait until Wednesday (will still make the test there), but...
I installed 5.18.0.2, Rider crashed directly when i minimized the NCrunch Tool Windows. Did not even have switch tool Windows, also i could "see" that there is something going on while resizing. It was not a smooth visual expierience.
Back to 5.19.0.3 .... drumroll ... smooth resize and no crash
Der-Albert.com wrote:Decided not to wait until Wednesday (will still make the test there), but...
I installed 5.18.0.2, Rider crashed directly when i minimized the NCrunch Tool Windows. Did not even have switch tool Windows, also i could "see" that there is something going on while resizing. It was not a smooth visual expierience.
Back to 5.19.0.3 .... drumroll ... smooth resize and no crash
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.
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.
Remco wrote:How is the freezing? Solved in the above build?
It worked better at first, but then I often only worked in one solution. In recent days, it's been freezing more often, especially when I have a very large solution (over 150 projects) open (without NCrunch enabled). It freezes multiple times, and when I click on a non-Rider window, it unfreezes again.
threadDumps-freeze-20251104-141546-RD-252.26830.109-Component.getLocationOnWindow-9sec folder (I can send the log in a contact form if you want): External image
Extra information:
I use always a 34 inch monitor 3440x1440 (home and at work). At work with my laptop screen (16 inch 1920x1200). At home a have a 34 inch monitor and two 24 inch monitors (1920x1080). I experience problems in both places.
Thanks for sharing this. In theory, the memory mapped receivers are all on background threads and shouldn't be able to directly cause a freeze. I'd really like a look at the logs. Are you able to send them through?
Remco wrote:Thanks for sharing this. In theory, the memory mapped receivers are all on background threads and shouldn't be able to directly cause a freeze. I'd really like a look at the logs. Are you able to send them through?
I have sent them in the contact form. Hopefully this is useful and you can identify the problem.
