Running mstest *without* it using a ThreadPool

Question

I'm writing some managed code to wrap a the native calls for IntervalZero's RTX product. RTX basically enables real time coding under Windows by setting up a kernel proxy. What's important here is that RTX generates the proxy when DllMain gets called with DLL_THREAD_ATTACH (and tears it down on DLL_THREAD_DETACH). If that proxy hasn't been generated and you make a call into the library, you get an immediate BSOD.

Well I'm 99.9% certain that when mstest.exe runs its unit tests, it queues them up using the ThreadPool class (it's the only thing that explains this behavior). The unfortunate thing there is that the thread has already been created before the RTX library is even loaded, so the DllMain is never called and RTX subsystem is unaware of its existence, and so when a unit test tries to call into the library things come undone.

I really need to be able to run unit tests on this stuff so I can get reasonable, automatable test coverage. is there a way to tell mstest to spawn a new thread at run time for each test? I know it would normally be slower to do that, but it's still going to be way faster than coming back up after a blue screen.

Answer 1

Have tried using a different framework than MSTest like nUnit to see if that reproduces the problem?

Answer 2

Well since my acceptance rate is low due to questions like this, I'll provide an answer (though not the one I like). I don't think getting mstest to behave differently (i.e. using a single thread per test) is feasible. I tried just about everything imaginable. The work-around for this was to write a simple test runner app that used reflection to load and run the tests. By doing this I kept the mstest syntax (though with a lot less features).

Longer term what needs to happen is that the RTX APIs need massaging to be more friendly. I'm working with the OEM to try to get that in the next release.