Jan,

Thanks for your suggestions! This is really helpful.

> 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.

Do you know how this is done?!

> 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).

This shouldn't happen since the DLL called is a '100% Squeak DLL' ;-) and
it's compiled under *exactly* the same settings as the VM.

> 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).

I've read about this but do you know how to find out if MMX mode is
currently active?!

> 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. 

Interesting - I've just checked RaiseException and you're right. I always
assumed that SEH is used for hardware exceptions only...

> 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.

Uh. Ah. Surely we don't want this ;-)

> This may be a useful test to see if any change in behavior
> happens.

Yep. Might be worth a try. Any volunteers?!

  Andreas