One of the create flags for D3D 9 devices is FpuPreserve. It tells the Direct3D runtime that you don’t want it to mess with the FPU flags, which it does to improve performance. And you should probably be using it.
FPU computations are a really hideously messy area, one that makes my head spin when you get into the details. One of the cool things .NET does is to take away most of the complexity and make very simple, straightforward guarantees about how floating point code must behave. Operations are done at specifically defined precision, in a certain way, and the runtime must enforce these requirements during code generation. (Which creates some weird x86 code.)
When DirectX goes in and messes with FPU state, it apparently throws off what .NET expects, leading to weird bugs of various sorts. So unless you’ve got some problem with FPU performance that can be solved by switching to the faster FPU states (hint: you don’t), it’s probably a good idea to simply set FpuPreserve all the time.
[EDIT] I forgot to mention as an addendum that as part of the SlimDX 2.0 transition, it’s very likely this flag will become the default.
Promit's Ventspace 
I hope this post means that you are taking some time to do a little bit of work on SlimDX again 😉
Very interesting read. I had only a vague idea of the complexity of floating-point operations, optimization side-effects and exceptions. It’s somewhat scary to know that some functions can alter the behavior of the FPU in such ways. Yet another thing that makes me happy to have stepped in the .NET world, where much of it is taken care of 🙂
I indirectly caused an “impossible” bug in a media player through my Direct3D plugin. The sample count for long audio tracks would be off by tens to hundreds of samples.
In the end, I hadn’t provided the FpuPreserve flag and thus caused the whole application, including the whole audio pipeline and all metadata calculations to run at single precision.