XUnit.v3 constant grid errors. Deserializes using the wrong node's path.

Hi,

I've been tearing my hair out for a week trying to figure out why I just cannot get my tests to run stably after upgrading to XUnit.v3.
I've kept getting intermittent torrents of this error in the test runner view:

NCrunch: This test was executed on server 'MANGES-LAPTOP'

This test was not executed during a planned execution run.  Ensure your test project is stable and does not contain issues in initialisation/teardown fixtures.

With errors like these in the grid node logs:

System.Exception: Tried to finish a test that was not expected to be executed
   at nCrunch.Module.XUnit3.ExecutionMessageSink.onTestCaseFinished(TestCaseFinished message)
   at nCrunch.Module.XUnit3.ExecutionMessageSink.OnMessage(Object message)

System.Exception: Tried to execute a test that was not expected to be executed: AccountId_is_empty(MicrosoftSqlServer:Microsoft)
   at nCrunch.Module.XUnit3.ExecutionMessageSink.onTestCaseStart(TestCaseStarting message)
   at nCrunch.Module.XUnit3.ExecutionMessageSink.OnMessage(Object message)

Well believe I finally managed to isolate it, and as far as I can tell it is an NCrunch bug.
The below stack trace is from from the node manges-laptop. Its workspace path is c:\NCrunchGridMangesLaptop\workspace\
but it is trying to deserialize using an assembly from the path C:\NCrunchGridThreadRipper\workspace, which is on another grid node.

System.IO.FileNotFoundException: Could not load file or assembly 'C:\NCrunchGridThreadRipper\workspace\66888\69\Tests\Integration\bin\Debug\net9.0\Compze.Tests.Integration.dll'. The system cannot find the path specified.
File name: 'C:\NCrunchGridThreadRipper\workspace\66888\69\Tests\Integration\bin\Debug\net9.0\Compze.Tests.Integration.dll'
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at Xunit.v3.XunitTestAssembly.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestAssembly.cs:line 146
   at Xunit.Sdk.XunitSerializableSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/Serializers/XunitSerializableSerializer.cs:line 19
   at Xunit.Sdk.XunitSerializer`1.Xunit.Sdk.IXunitSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/XunitSerializer.cs:line 39
   at Xunit.Sdk.SerializationHelper.DeserializeXunitSerializer(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 429
   at Xunit.Sdk.SerializationHelper.Deserialize(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 337
   at Xunit.Sdk.XunitSerializationInfo.GetValue(String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfo.cs:line 79
   at Xunit.Sdk.XunitSerializationInfoExtensions.GetValue[T](IXunitSerializationInfo info, String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfoExtensions.cs:line 35
   at Xunit.v3.XunitTestCollection.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestCollection.cs:line 115
   at Xunit.Sdk.XunitSerializableSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/Serializers/XunitSerializableSerializer.cs:line 19
   at Xunit.Sdk.XunitSerializer`1.Xunit.Sdk.IXunitSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/XunitSerializer.cs:line 39
   at Xunit.Sdk.SerializationHelper.DeserializeXunitSerializer(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 429
   at Xunit.Sdk.SerializationHelper.Deserialize(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 337
   at Xunit.Sdk.XunitSerializationInfo.GetValue(String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfo.cs:line 79
   at Xunit.Sdk.XunitSerializationInfoExtensions.GetValue[T](IXunitSerializationInfo info, String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfoExtensions.cs:line 35
   at Xunit.v3.XunitTestClass.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestClass.cs:line 118
   at Xunit.Sdk.XunitSerializableSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/Serializers/XunitSerializableSerializer.cs:line 19
   at Xunit.Sdk.XunitSerializer`1.Xunit.Sdk.IXunitSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/XunitSerializer.cs:line 39
   at Xunit.Sdk.SerializationHelper.DeserializeXunitSerializer(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 429
   at Xunit.Sdk.SerializationHelper.Deserialize(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 337
   at Xunit.Sdk.XunitSerializationInfo.GetValue(String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfo.cs:line 79
   at Xunit.Sdk.XunitSerializationInfoExtensions.GetValue[T](IXunitSerializationInfo info, String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfoExtensions.cs:line 35
   at Xunit.v3.XunitTestMethod.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestMethod.cs:line 132
   at Xunit.Sdk.XunitSerializableSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/Serializers/XunitSerializableSerializer.cs:line 19
   at Xunit.Sdk.XunitSerializer`1.Xunit.Sdk.IXunitSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/XunitSerializer.cs:line 39
   at Xunit.Sdk.SerializationHelper.DeserializeXunitSerializer(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 429
   at Xunit.Sdk.SerializationHelper.Deserialize(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 337
   at Xunit.Sdk.XunitSerializationInfo.GetValue(String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfo.cs:line 79
   at Xunit.Sdk.XunitSerializationInfoExtensions.GetValue[T](IXunitSerializationInfo info, String key) in /_/src/xunit.v3.common/Serialization/XunitSerializationInfoExtensions.cs:line 35
   at Xunit.v3.XunitTestCase.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestCase.cs:line 239
   at Compze.Tests.Infrastructure.XUnit.PluggableComponents.PluggableComponentsTestCase.<>n__1(IXunitSerializationInfo info)
   at Compze.Tests.Infrastructure.XUnit.PluggableComponents.PluggableComponentsTestCase.<>c__DisplayClass6_0.<Deserialize>b__0() in C:\Dev\Compze\src\Tests\Infrastructure\XUnit\PluggableComponents\PluggableComponentsTestCase.cs:line 53
   at Compze.Utilities.SystemCE.VoidCEExtensions.<>c__DisplayClass1_0.<AsUnitFunc>b__0() in C:\Dev\Compze\src\Compze\Utilities\SystemExtensions\SystemCE\VoidCE.Extensions.cs:line 18
   at Compze.Utilities.Logging.ExceptionLogger.ExceptionsAndRethrow[TResult](ILogger log, Func`1 func) in C:\Dev\Compze\src\Compze\Utilities\Logging\ExceptionLogger.cs:line 25
   at Compze.Utilities.Logging.ExceptionLogger.ExceptionsAndRethrow(ILogger log, Action action) in C:\Dev\Compze\src\Compze\Utilities\Logging\ExceptionLogger.cs:line 35
   at Compze.Tests.Infrastructure.XUnit.PluggableComponents.PluggableComponentsTestCase.Deserialize(IXunitSerializationInfo info) in C:\Dev\Compze\src\Tests\Infrastructure\XUnit\PluggableComponents\PluggableComponentsTestCase.cs:line 51
   at Xunit.v3.XunitTestCase.Xunit.Sdk.IXunitSerializable.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestCase.cs:line 260
   at Xunit.Sdk.XunitSerializableSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/Serializers/XunitSerializableSerializer.cs:line 19
   at Xunit.Sdk.XunitSerializer`1.Xunit.Sdk.IXunitSerializer.Deserialize(Type type, String serializedValue) in /_/src/xunit.v3.common/Serialization/XunitSerializer.cs:line 39
   at Xunit.Sdk.SerializationHelper.DeserializeXunitSerializer(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 429
   at Xunit.Sdk.SerializationHelper.Deserialize(String serializedValue) in /_/src/xunit.v3.common/Serialization/SerializationHelper.cs:line 337
   at Xunit.Runner.InProc.SystemConsole.ProjectAssemblyRunner.Run(XunitProjectAssembly assembly, IMessageSink messageSink, IMessageSink diagnosticMessageSink, IRunnerLogger runnerLogger, ITestPipelineStartup pipelineStartup, HashSet`1 testCaseIDsToRun) in /_/src/xunit.v3.runner.inproc.console/Utility/ProjectAssemblyRunner.cs:line 258

Hi, thanks for sharing this issue.

The first thing I always think about when I see the runner experiencing sequence failures like this is to check for asynchronous behaviour.

NCrunch needs a test run to be entirely synchronous. It does inject settings into Xunit to force synchronous behaviour, but it's possible there are user settings or attributes that might override this. If you have anything that could be suspected of forcing asynchronous behaviour, try commenting it out or turning it off to see if it makes any difference. If the runner tries to execute tests asynchronously, you'll see a lot of errors like 'System.Exception: Tried to finish a test that was not expected to be executed'.

Can you share any more details on where you caught this deserialization stack trace? Was it reported in the Tests Window?

I think this is being caused by complex types being serialized during the test discovery step (probably as parameters to tests), then attached to the test metadata and passed through into execution. Xunit then tries to deserialize them in the expectation that the original assembly is readily there, which in this case it isn't. Can you show me the signature for this test? (along with any Xunit attributes and types involved).

I don't really understand what you are saying. We have a ton of asynchronous tests...
The code is all open source though and the commit that added the logging you are looking at is here: https://github.com/mlidbom/Compze/commits/xunit_v3/

To be honest I have a very hard time imagining this as anything but an ncrunch problem.
Code is running expecting to deserialize from a folder on another ncrunch grid node than the node the test is executing on... Surely it must be NCrunch's responsibility to see to it that this does not happen?

Sorry, I can read the frustration you're experiencing here.

I'm not trying to debate ownership of problems. I appreciate this has been driving you mad all week.

I'm just trying to get more information so I can help solve this. If you're able to share the signature of the test that's triggering the deserialization problem, I should be able to analyse this further.

Async tests by themselves are nothing unusual, I was merely probing as to whether you knew of any settings or overrides you have in place that might try to affect or force asynchronous execution. I'm not personally familiar with any of these in Xunit3, but NUnit has a few of them, and I'm not confident enough to claim I know what all of them are.

Any detailed information you can share upfront is a huge help. I understand your solution is open source, but it sounds very large and could be a bit of work setting up for a problem that I might be able to otherwise isolate very quickly.

Thank you for another quick response.

I would love to give you the information you are asking for, but for a week trying to get clear information from NCrunch about which tests are actually the problem has eluded me. Run after run with no problem, then suddenly one failure, or a torrent with hundreds of them.
There is precious little information in the NCrunch logs in the UI. And if I turn on logging to file on a grid node with anything above summary, there is such a torrent of logging that I struggle mightily to find anything in the deluge.
I spent a week believing that the problem was in our code, but I honestly very much doubt that now.
Tests ranging from using my custom attributes to tests using another custom attribute to tests using plain Fact or Theory have been crashing right and left since I upgraded with little to no discernible pattern other than that as long as I only use one grid node everything is rock solid. But goodness the frustration it took before I realized that as long as there was no distribution there was no problem....

Please note this from the stack trace:
at Xunit.v3.XunitTestCase.Deserialize(IXunitSerializationInfo info) in /_/src/xunit.v3.core/ObjectModel/XunitTestCase.cs:line 239

This is line 239 in XunitTestCase.cs:line 239

testMethod = Guard.NotNull("Could not retrieve TestMethod from serialization", info.GetValue<IXunitTestMethod>("tm"));

As far as I can tell XUnit is just trying to get access to the information about the test, but when doing so tries to find the test assembly on another grid node....


As for our solution being big. Yes. Can't deny it. But since a while ago you can run the tests without any external dependencies by configuring it to use an in-memory Sqlite for the tests.

The setup amounts to cloning and copying src/TestUsingPluggableComponentCombinations.example to src/TestUsingPluggableComponentCombinations and compiling.
Hmm. actually even the copying step should be handleid by msbuild now I believe. So cloning and compiling should be all...

Magnus Lidbom wrote:
I would love to give you the information you are asking for, but for a week trying to get clear information from NCrunch about which tests are actually the problem has eluded me. Run after run with no problem, then suddenly one failure, or a torrent with hundreds of them.
There is precious little information in the NCrunch logs in the UI. And if I turn on logging to file on a grid node with anything above summary, there is such a torrent of logging that I struggle mightily to find anything in the deluge.
I spent a week believing that the problem was in our code, but I honestly very much doubt that now.
Tests ranging from using my custom attributes to tests using another custom attribute to tests using plain Fact or Theory have been crashing right and left since I upgraded with little to no discernible pattern other than that as long as I only use one grid node everything is rock solid. But goodness the frustration it took before I realized that as long as there was no distribution there was no problem....

Understood. Problems of this nature have sadly formed quite a large part of my life for the last 17 years, and I understand that to call them _infuriating_ is an understatement. Because we're exchanging quite often on this forum, I feel it's best I level with you a bit here.

Imagine having the above thrown at you on a Sunday, with a week of frustration behind it, along with no clear steps to reproduce and a lot of implied blame. I do my best to help people with issues like this here, but it's never nice to be treated like a target.

With that aside, I've done my best to analyse this issue and understand it. The solution you've shared didn't manage to pass its DB tests for me, but fortunately that wasn't necessary, as the problem is around test discovery and execution, not the results.

I wasn't able to reproduce the stack trace you've shared, but I COULD reproduce the other stability related errors when discovering the AccountManagement tests on one machine and executing them on another. I've had a look through the custom attributes in your code and through the related Xunit serialization logic and I've managed to draw a few conclusions about what is happening.

When Xunit discovers tests, there are a couple of very important things that it does:
1. It generates unique identifiers for each test case. These aren't just method names, they also include parameters details for theory cases and other information used to identify a test no matter which domain it is in.
2. It serializes details about the test, capturing it in such a state that the same test can be deserialized in a different process and executed consistently

This is a process that is generally transparent when all is well, but introduces a large amount of very necessary complexity, because we need to be able to find a test in one process/environment, then transfer it to be run in another one, and have all the results make sense. For tests with simple scalar parameters, it's not so bad, but when you start deconstructing the sorts of types that people pass into test parameters, it gets easier to understand why there is a higher chance for things to go wrong here. Serialization of arbitrary types is complex. In this situation, when it fails, it's hard to get reliable information that can help with solving the problem.

It's for this reason that I am a strong advocate of keeping your test parameters as simple as possible. If you need to build complicated types to represent your tests, it's better to use strings instead and instantiate the types inside the test code itself.

Anyway, the root cause of these problems seems to be that the serialized data for your tests is including the assembly path as it exists on the machine responsible for discovering the tests. As you've identified, this path is not necessarily the same on the machine executing them, and this causes stability problems such as the inability to identify the tests being run, and the potential for type resolution issues during deserialization.

Xunit.Sdk.SerializationHelper contains logic that includes the assembly file path in the serialized data. So this problem is not specific to your code - it's a broader issue that I've now raised with the Xunit team to see if they can suggest a way to solve it. I've managed to reproduce the issue myself with a small code sample making use of an IXunitSerializable parameter in a theory testcase.

In Compze.Tests.Infrastructure.XUnit.TestFrameworkExtensions.XFactAttributeTestCaseDiscoverer I've tried removing the logic that manually constructs test IDs, and I found that this significantly helped with stability to the point where I was no longer able to immediately reproduce these issues in the Compze solution. This doesn't mean that adjusting this logic makes everything OK, because it's not. Right now any Xunit3 test metastructure that drags in a System.Type can hit the above problem with distributed processing. I also have serious concerns about these custom attributes and the way that they work.

It's a general policy in NCrunch that we don't officially support people implementing custom test attributes. This is regardless of framework (NUnit, MSTest, Xunit), and it's for a very good reason: When you're doing this, you are fundamentally changing the way the toolset works, and it's utterly impossible for NCrunch (or its developers) to predict exactly how everything will behave. Put simply, we can't warrant that NCrunch will work correctly when you do this. There's no amount of testing we can do or support we can offer that will provide any guarantee of stability with a modified test framework.

That doesn't mean that it can't work. It just means that if you do this, please don't expect help from us. I really can't stress this enough. When you implement your own test framework attributes with the intention of changing framework behaviour, you are playing with fire. It can result in you living in a horrible hellish nightmare of weird intermittent problems that are nearly impossible to analyse and can appear or disappear seemly at will. The past week of your life will likely have been very instructive in this. With the weight of all my experience in this area, I will tell you that whatever syntactic benefits you hope to achieve with this approach, it's never worth it.

I'm hopeful that we'll hear back from the Xunit team on this issue. Right now I can't find a way to fix this in NCrunch. For the time being, for anyone affected by this, I recommend one of the following:
- Avoid using custom types on test parameter lines
OR
- Avoid multi-node execution (distributed with a single node and no local should be fine)
OR
- Rollback to Xunit v2

Thank you again for researching this so fast.

I apologize about my tone. I did try to rein in my frustration, but obviously I failed.
I truly did not intend to force you to handle this during your weekend. I have already migrated back to v2 since I just could not get this stable.
I'm truly sorry I made you feel you had to give up your weekend to look at this right away. I know what that feels like and it was absolutely not my intention.
Again. I'm sorry.

I'm afraid I was not aware of the, no custom attributes allowed limitation. I assume it is there in the documentation, but I must admit to not having read that for some time.

In Compze.Tests.Infrastructure.XUnit.TestFrameworkExtensions.XFactAttributeTestCaseDiscoverer I've tried removing the logic that manually constructs test IDs, and I found that this significantly helped with stability to the point where I was no longer able to immediately reproduce these issues in the Compze solution.

Ironically, that code was introduced to try to debug the problems in NCrunch and we actually thought we saw things get better with it. With this kind of intermittent issue, determining whether a change one makes actually improved things or not can be "non trivial" to say the least!

On the value of our customizations:

To me the value of the customizations is not in question. It fundamentally changes how we can write tests, allowing us to write:
- tests that run the cross join of all of the pluggable components supported by the Compze framework.
-- When adding support for both SQLite and SQLite in-memory-mode, the additional tests we needed to write were literally 0. Imagine what this means...

- BDD style test using nested-inherited classes
-- gradually building up the current context constructor by constructor
-- trivially easily assert at each context level since all the state is already in place and only the assertions need to be written
-- forming a human readable specification of the behavior as a whole including each context level

To me both of those are simply irreplaceable.

No doubt the perspective of a person that deals constantly in the complexities this causes for test runners will differ from mine, but to me the above is so vital that the day I cannot get this to work in NCrunch is not the day that I stop writing tests that way, it is the day I stop using NCrunch.

And that is coming from a super advocate for NCrunch. I cannot count the times I've told people they should be using NCrunch. The effort NCrunch has saved me is immense. NCrunch is an absolutely fantastic product.

And still the above holds. That is how important, to me, those two things are. NCrunch is a game changer, but those two things, to me, are game replacers. They change the paradigm.

Thankfully the dreaded day I'm forced to abandon NCrunch is not today. XUnit v2 still works just fine and I sincerely hope that by the day that abandoning v2 becomes unavoidable, I will be able to get our tests to work in NCrunch with v3.

I went to sleep after my last post, woke up to Brad's comment: https://github.com/xunit/xunit/issues/3419#issuecomment-3419774531, and I've spent most of my time since then refactoring to see if I can get things stable leveraging that and your tips.

Now:
- our v2 code is greatly transformed
- our v3 code is rewritten from scratch
- all the XUnit customizations are extracted into separate projects and slnx: https://github.com/mlidbom/Compze/blob/xunit_v3/src/Compze/Utilities/Testing/XUnit/Compze.Utilities.Testing.XUnit.slnx
- as far as possible, without losing the benefits I described above, I have followed your recommendations as I understood them. In particular, keeping custom types out of the serialized data and the test method arguments.
- I added the .uniqueid file mentioned in the post to all our test projects

The end result is that our custom attribute tests now all run stable in NCrunch even when distributed across grid nodes!
A big think you for the tips :)

But:
- Grid nodes, one in particular curiously*, logs a torrent of the errors mentioned above, but for some reason this never fails the tests.
- I've isolated another issue, which I don't think fits with the issues you mentioned on github, which you can find here: https://github.com/mlidbom/Compze/blob/xunit_v3/src/Compze/Utilities/Testing/XUnit/v3/NCrunchErrorReproductions/TheoriesCrashInNcrunchChurnMode.cs

The latest code for all of this is on the xunit_v3 branch.

(*) It might be relevant that this is a "true" distributed node, running on another machine than the machine running NCrunch in Visual Studio, while the local node I installed to do this testing for some reason does not log these errors, or at least hardly ever ....

I hope this is useful to you.

Cheers!

Oh, it might be helpful to know that I've observed an interestingly consistent failure mode with the standard theories failure linked above.
It seems that one test always fails quickly, and after that churn mode seems completely stable and no more tests in the theory fail.
I could have sworn that it used to be a random test that failed, but now when I test it it seems to always be the first test in the theory.
Maybe the changes I made to make the reproduction minimal changed the behavior somehow....

I've had some inspiration. Rather than trying to have xunit avoid encoding the assembly path into the test IDs, I've rigged up the remote node so that it will copy the locally discovered test metadata into the test before it begins execution (from the analysis task on the remote node). In this way, the test is only ever run with metadata that was discovered from the assembly being used to execute it. Thus we structurally avoid the problem entirely.

Would you be interested in trying the build below to see if it solves the problem?

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

Everything runs solid as a rock now with that fix in place.
Thank you so much :)