Hi! Thanks and hats-off for the super-quick feedback Chris!
My crash-reports folder does contain several .dmp-files, 2 of which are dated today, but they do not appear related to these crashes/lock-ups. I just produced a few new crashes but no new .dmp-files show up in that folder.
New findings/summary:
The problem also occurs in a single-monitor scenario with just two views open with at least one undocked.
Quick-mask-mode works without any problem. It's only as soon as the marching ants come into play that it triggers.
With OpenCL disabled, sometimes selection is possible without actually crashing but the UI becomes so unresponsive and stuttering that any further selection with ie freehand-tool becomes unfeasible until the second view is closed.
I tried per your suggestion with a small 8-bit RGBA document with a single pixel-layer, but the problem exists even there, though it does take longer before crashing/slowing down.
On crashing, one or more of the following happen:
AF stops responding to input, gets a milky white overlay and Windows places the "(not responding)" in the title-bar. Once in a while, the application title-bar blinks as if recovered but then immediately returns to "(not responding)". This is basically the loop it gets stuck in until the app-process is killed via Task Manager.
Occasionally, AF crashes silently back to desktop after a few moments in the loop described above.
On very rare occasions it's possible to close the second view and then AF seems to recover. Most of the time, this is not possible since the UI has stopped responding.
What tool would I need to produce a screen recording?
Best regards,
Mans.