Daily Usage Issues

NCrunch 2.23 causes InvalidProgramException to be thrown with exception filtering

Started by vesap on 6,616 views

Using the exception filtering causes the tests to fail due to InvalidProgramException, for example:

try
{
  // Do something
}
catch ( AggregateException ex ) when ( ex.InnerException is HttpException ) { } // removing when-predicate gets rid of the InvalidProgramException


I tried this on two PCs, other on Win10+VS2015+NCrunch 2.23 and the other on Win7+VS2015+NCrunch 2.19. The latter works fine but the former causes the InvalidProgramException to be thrown. I tried downgrading to NCrunch 2.19 on the Win10 PC but there was no difference.

So it seems like it is some Win10-specific issue. Any ideas how to resolve it?

Thanks!
Hi, thanks for sharing this issue.

This is likely being caused by NCrunch's instrumentation. There must be something in the CLR that doesn't like code within the exception filter from being instrumented. It's interesting that this only happens on Windows 10. I'll need to investigate this more before I can arrange a fix.

For the time being, I recommend disabling instrumentation on this code using NCrunch's code coverage suppression comments, for example:

try
{
// Do something
}
//ncrunch: no coverage start
catch ( AggregateException ex ) when ( ex.InnerException is HttpException ) { } // removing when-predicate gets rid of the InvalidProgramException
//ncrunch: no coverage end
Hi Remco

We are also experiencing this issue. Have you had an opportunity to investigate further?

We're running Windows 7, if that makes any difference.

We have a catch on a SqlException, when exception.Number == 2627.
Hi! Yes, I've managed to isolate and resolve this issue. A fix will be available with 2.27, out within the next couple of days.
Great stuff. What was the cause, out of interest?
It was actually a bug in Cecil, since fixed in Cecil's main dev branch. It wasn't correctly calculating the max stack size for methods using exception filters. Up until recently, the bug hadn't been a big deal because exception filters weren't available in C#. The issue didn't appear for all methods, because sometimes methods would have other code that would increase the max size of the stack over the required threshold. This made it hard to reproduce without a good code sample. Changing the structure of the method by adding extra method calls outside the exception filter will probably solve it in isolated situations.

Post a reply

Log in to reply.