Closed nietras closed 6 years ago
@nietras , vstest.executionengine.exe does not explicitly tires to reset MxCsr register, but like you mentioned if you native dll is loaded once in the process, it's DllMain won't be called again. To resolve this issue all you have to do is uncheck Test->TestSettings->Keep exe running option, which would kill vstest.execution engine after every run.
However since VS2017 update 5 we have introduced a new test platform, which will always kill the testhost (new vstest.executionengine) process, where tests are run.
Hi, I am closing this, it appears that for some reason even when using DLL_THREAD_ATTACH
that the native dll did not change the MXCSR register for anything but the first thread that actually caused the native dll to be loaded. On subsequent tests different threads are used which do not get the proper bits set in MXCSR and we see differences in floating point results. Not a vstest issue, but an issue with the native dll.
I am having some issues with reproducibility of tests in the face of a native dll that changes the
MXCSR
registerFTZ
(flush-to-zero) andDAZ
(denormals-are-zero) bits inDllMain
when process is attached.Running this first time inside Visual Studio causes
vstest.executionengine.x86.exe
to start and then load the native dll and the test is run. This gives the expected result.However, upon subsequent test runs inside Visual Studio the test fails, seemingly since the
MXCSR
register has been reset. Sincevstest.executionengine.x86.exe
keeps running and keeps the native dll loaded, this meansDllMain
is not called again.Forcibly killing
vstest.executionengine.x86.exe
and running tests again results in the test succeeding again the first time it is run.My question then is, does
vstest´ change/reset the
MXCSR` register?Note, that we only run a single test method. Which only touches well known code in the native dll. The function itself does not set the
MXCSR
register.