>No, not really ;-) So you've got a Pentium MMX ... hm ... I have absolutely
>no idea what's going on here. If there's somebody out there who could give
>me a clue I'd really appreciate it...

A few ideas...

1) An exception 10H is a math coprocessor fault. I believe you could get a
fault on storing a value if the math coprocessor control flags were set to
cause an exception on a variety of errors, instead of the mode to just fix
things up and continue. Setting the coprocessor flags get's especially
sticky if you call a DLL, and the DLL may have some different assumption
about the coprocessor mode flags than the program (or a different DLL). To
be squeaky clean, a DLL should always set the coprocessor mode before doing
FP work, and then restore it to whatever it was before the call. In the
real world, DLL's often don't do this, they just make some assumption, or
expect the calling program to explicitly set the mode, they even sometimes
have functions to set the correct mode before other DLL calls.

2) Some piece of MMX vector code is forgetting to reset the FP register
state after doing MMX instructions. As the MMX registers are mapped on top
of the FP registers, the FP instructions will fault, because the processor
still thinks your in MMX mode and the FP registers are not empty (can look
like a FP stack overflow).

You can probably make the MSVC debugger trap the exception, you just have
to add an exception code 10H to the list of known exceptions and tell it to
always trap it. Actually, exceptions can have just about ANY number as
software can call RaiseException with any value. It might be useful to look
at the FP mode and staus registers at the time of failure. As I remember,
you can tell from the FP status register if things are still in MMX mode.

The Microsoft Knowledgebase also says you can turn off the math coprocessor
from the control panel (to avoid buggy coprocessors), and rely on software
FP emulation. This may be a useful test to see if any change in behavior
happens.

- Jan