Right now it is possible and indeed likely for our Acceptance Tests on Windows to leave the system in an inconsistent state since they have no means of detecting when the system starts and finishes honouring particular settings updates. And if our test cases can fail in this way, it is certain that the live realtime system can as well.
The most vulnerable settings seem to be those operated by the SPI settings handler on Windows. Even on a lightly loaded system, these settings (e.g. contrast/desktop settings) can take a significant period of time to even start being applied, and if a further SPI call to the same API is issued within this window, the result will be a corruption of the settings and a loss of the user's original state.
There seems to be no official or standard means of detecting this update, but it seems likely that by registering a listener to "all" broadcast Windows events we can probably find something in the stream that we can reliably correlate with the update - and the settings handler itself should block the FlowManager until this update is received.
This work interrelates to the work for
GPII-580 since it is one of the avenues that can lead to loss of a user's settings. In the case we don't pursue this JIRA itself in a timely way, we need to add facilities to the GPII-580 solution to make sure that it makes "repeated attempts" to restore the very first in a stack of related SPI updates, in the case the system is restarting, until it can detect it is successful. One other possibility is a "GPII reset" utility which tries to make best efforts to restore a consistent set of settings even in the face of this issue - for example by maintaining a history of several previous "initial session snapshots" in the case the user has managed to try to log on several times in succession but each logon has broken in some way without the cleanup being effective.