With regards to this topic I did a littel more investigation, since we now want to alter registry settings during runtime.
The issue is: When you save the registry and restart the system the order of keys in the (exported) registry gets inverted.
- export HKEY_LOCAL_MACHINE to file
- save registry
- export HEKY_LOCAL_MACHINE again
- compare files
Sofar I couldn’t find any issues with this behaviour except for the unified touch driver:
The inverted order disables the touch driver.
Workaround ist to move the FlashDisk dependency out of the touch driver and put it into the I2C1 driver:
You did quite some thorough investigations to track down your issue. Here are my comments:
The registry settings are basically not ordered, so nothing should rely on the order the settings are read.
The different behavior you have seen is possibly not caused by the swapped order within
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch\DependsOn], but by some general small timing shifts in the boot process, which might be caused by different load orders or by other randomness in the system.
I currently have no explanation why your first implementation doesn’t work. If you are fine with your workaround, we can stop the investigation here. Otherwise could you please Enable the debug messages and send us the debug output for a working and a non-working case.
I think you mentioned the wrong Thomas @andy.tx
This answer was probably meant for @t_achmann
Hi @andy.tx ,
I agree, that this is a timing issue. It would be very strange, if the registry would rely on any ordering.
Sofar it works for us. I2C is not used in our system except for the touch and touch needs the flash disk anyway(driver). I think we can leave it as is. If we have some more time to investigate, I will send the dbg msgs.
Thanks for looking into it.
You are right of course. Thank you for pointing this out, sometimes autocompletion is not helpful…