I can confirm that there is same problem on linux, too.

Yes, close it. The problem seems to be related to the rate at which blender/other uses CPU SIMD memory. The assembler code is not easy to read into why values returned are causing an exception.

OKI, closing then, since it seems it’s not related to Blender.

With further research into the NT kernel library functions have seen that this is sometimes the case.
Blender does work with the objects and scene given. It is something in the low level OS that
caused the first few crashes. Thanks.

I've added a debug file that shows it is doing nothing very slowly. "blender_debug.txt"
Very slow at less than 1 fps.
I can lower the number of particles/hairs and does great.
The crashes started then stopped, and now animation is very slow. That crash data is in the original post.
Would be interested to see the differences in computer systems.

First animation play though is a little slow , but once cached it seems to play flawlessly at 18fps , what's steps are required to make it crash?

Can confirm the behavior, unable to say if this expected behavior though. @Sergey Sharybin (sergey) ?

Can confirm the behavior, however, it's working as designed, and even if we were to go out and change this behavior it's not and easy fix and it is likely that the physics will get some rework in 2.8 anyhow, so I'm gonna have to classify it as a feature request and close it, we'll revisit once the physics code in 2.8 gets some love.

I can't seem to be repro at all, given you solved the issue your self i'm gonna close the ticket, if you ever come up with a fool proof set of steps to trigger the issue we'd happily take a look at it though.

Please attach a .blend exhibiting the issue.

Well it seems Vertex Weight Proximity is not the problem, another modifiers like Subsurf or Triangulation placed before second Displace also break simulation

Disabling the disk cache (after invalidating it) for all objects solves both problems.

The result of my tests so far:

• If I free all bakes and invalidate the cache, the simulation runs ok at first. Replaying it makes it crash.
• Disabling the disk cache makes it crash.
  condensation.disable-disk-cache.crash.txt768 B

  Download
• If I free all bakes, invalidate the cache, and run the simulation again, it doesn't crash. I still have the bug where I can't see all particle systems though. Strangely enough, this time I see two of them, the active one and another that "jumps" between meshes. Here's a video.
  jumping-particles.mkv907 KB

  Download

This is caused by dynamic paint doing its own object data updating (BKE_object_modifier_update_subframe) which runs at the same time as the scene_update_object_func task see:

I removed dynamic paint and and applied again now its working.
Thank you for your help.

Confirmed. This crashes here.

Allrigt, i see! Very nice from you- thank you very much. I understand what was going wrong!

Thank you for this information!

Stripes are not due to adaptive domain. Blockyness was due to adaptive domain .
Stripes are consequences of physics settings.

Thank you for the quick answer.
Ive checked this with a new domain, applyed scale, disabled addaptive domain. The effect is still there.
See the screenshot:

It is a side effect of using adaptive domain.
Disable it. Recenter and scale a little bit the domain. And blockyness in simulation should be gone.

Ive made a test with the maximal resolution of 512 and highres 2 - of course artifacts become smaller and less visible - but they are still there. It looks like smoke would have friction/is sticky to the simulation´s grid cells.
https://www.youtube.com/watch?v=EInB32aKuNo

This is not really a bug but more of a limitation.
I have a patch that does proper deactivation in the rigid body improvements branch, but it wasn't committed because it wasn't clear how deactivation should be handled in blender in general.
I might dust if off since this really can be preveived as a bug.

This is intentional behaviour. "Final" includes generative modifiers which don't just deform the mesh but generate a new one.
Now we could do shenanigans like rebuilding the collision shapes every frame, but that would be extremely slow and unstable.

Bah, am now getting a straight crash when trying to switch to Cycles viewport render…

And the bug was introduced on rB272412f9c0d26.

It was working on v2.78a, and broken on v2.78c.

This might not be the right place to discuss. However, I don't really understand this:
If you have added a texture to a particle (hair) system, and you hit 'Bake', you get an 'empty bake', that is a simulation doing nothing. Ignoring all fields you have added. Without any warning or notice, that you have to remove the texture again before you can get a usable result. To be more clear, you get an 'erroneous result' without any hint why. This is considered a limitation?

Yes. It is an already reported problem. Not really a bug but a known limitation.

Is it fixable in future blender releases?

Perhaps this is related to a couple of the "archived" bug reports?