Inconsistent results using RegistryNotifyCallback vs RegistryNotifyWindow

Question

(I'm on WM 6.5)

I started using ::RegistryNotifyCallback when monitoring parts of the registry, but noticed that some notifications that should arrive never did. I switched to ::RegistryNotifyWindow and the missing notifications arrived as expected. I don't remember the repro steps, since it was a while back, but now I'm forced to go back to the callback version for other reasons [1], and I wanted to iron out that initial doubt if possible.

• Has anyone noticed any "success discrepancies" between the callback and window message versions?

• Is it even likely/possible that the two would function differently? I assume that both the callback and posted window message have the same origin code-branch-wise, I even imagine that RegistryNotifyWindow is implemented by means of RegistryNotifyCallback in the WM core, so that the decision between calling the callback or posting the message is a really late activity (in the CE/WM state and notification broker core) and a bug there on MS's side seems quite lame...

[1] There's a race condition that sometimes causes some registry changes to be notified before the changes are actually persisted/flushed to the registry, so reading the value when getting the notification gives the wrong result. However, the "new value" supplied with the callback data parameter and with the window message's WPARAM is indeed the correct values that have not yet been flushed to registry. Since ::RegistryNotifyWindow only supplies DWORD values and I need string and binary values, I must change to ::RegistryNotifyCallback, which correctly handles all registry value data types (I don't want to ::Sleep for a second to ensure that the values are flushed by the state and notification broker)

Answer 1

After more than a week of testing, I conclude that the callback version is at least as stable as the window message posting version, but much more versatile due to the full handling of all registry value types, not just REG_DWORD, but also strings and binary. I therefore recommend the callback version, although marshalling data to the UI thread must then be made manually.