MKL and IPP act as native code, invoking the Intel OpenMP library, and in turn the Windows threads. Upon completion of an OpenMP task, the OpenMP library will hang onto the threads for an interval adjustable by KMP_BLOCKTIME (default 200 milliseconds). CLR ought to regain control of threading once that interval has expired. If you are starting OpenMP from multiple CLR threads, you probably should adjust OMP_NUM_THREADS or MKL_NUM_THREADS so that the total number of cores demanded matches your platform.
I suppose it's possible the OpenMP library makes conflicting use of the Windows threads affinity masks. Ideally, when OpenMP starts up, if using the same low level threading library, it should respect the masks, and not create additional threads unless OMP_NESTED is set, but I would not be surprised if neither the developers of CLR threading nor OpenMP planned for such cooperation. You could test one of the ways of making MKL single threaded (set MKL_SERIAL, or link with /Qmkl:serial), which should prevent MKL from tinkering with any threading settings. As you have already threaded the application, the MKL serial might prove best if you start it from a CLR thread.
Persuading each OpenMP task to run within the cores used by the parent CLR task is another question, probably beyond the scope of the C++ forum.
