This stack seems bogus to me. I don't see how PCompositorBridgeChild::SendPLayerTransactionConstructor() could call AddObserver(). Seems likely that gfx is doing something with unallocated memory here.

There are at least two causes of the crash here.
356 out of 412 crashes are from uses of the observer service off the main thread. The assertion is "Using observer service off the main thread!". The ten or so of these crashes I looked at were all from some rapporttanzanex430.dll calling into the observer service from off the main thread. Maybe we can block that DLL or something? Here's an example: bp-89766b30-d496-427c-8700-df1682160816
In the second crash, like the one linked in comment 0, we seem to be reentering the observer service while sending an IPC message. I'm not sure how that can happen, and that doesn't seem like it would by itself cause the crash. Maybe we hit some garbage and are just calling something random? On 51, there are 19 crashes from 2 installations.

(In reply to Andrew McCreight [:mccr8] from comment #2)
> In the second crash, like the one linked in comment 0, we seem to be
> reentering the observer service while sending an IPC message. I'm not sure
> how that can happen, and that doesn't seem like it would by itself cause the
> crash. Maybe we hit some garbage and are just calling something random? On
> 51, there are 19 crashes from 2 installations.
Or the stack is bogus, like Ben mentioned, and we need to look at things in windbg. The random addresses in the backtrace lend credence to that theory.

So presumably most of the crashes the bot found in comment 6 really should be reported on bug 1295600? I don't know if there's a good way to stop it from clobbering the flags.
CC'ing dvander for since IPC calling into garbage seems like it's in his wheelhouse.

And actually it looks like there were no crashes beyond the 20160815030201 build, so it might have been something that got backed out already. This is probably WFM now, with bug 1295600 tracking the dll issue.