Very difficult to know what is going on. Are you installing your own service executable as part of your MSI? If so it will be a "self repair" entry point when invoked (start / stop). This means that all key paths in all components will be verified on the fly and if any key paths are found to be missing a reinstall of your application is performed automatically. You can use a verbose log file to determine what component triggered self repair. Use the Windows Installer Command Line Builder to construct the msiexec.exe command line to create the file. See my answer here: How to interactive a silently installing msi? (Progress data and cancel it)
Note that you can also generally find the component responsible for the self repair by checking the system's event log. This is the fastest approach. A log file will give you more information. To make sense of the log use Microsoft's own log file analyzer: http://msdn.microsoft.com/en-us/library/windows/desktop/aa372811(v=vs.85).aspx
If you are hard coding registry keys in the msi, they will indeed tend to be reset when the repair is done. When you point an MSI component towards a registry path as key path, the MSI file thinks it "owns" that key and will reset it on install and remove it on uninstall unless you design the MSI file specifically to avoid this. You can avoid this by setting the component as "permanent" and "never overwrite if keypath exists". A better option is to have the service exe file write its own defaults to the registry after installation if it has permissions to do so. This will decouple your settings from MSI and the installer will never mess with them.
If my gut feel is correct your service exe file is resetting registry values that the MSI thinks it "owns" and starting the service triggers a key path check that in turn triggers a self repair to revert the values to the MSI defaults. Sorry for the messy explanation, but I am shooting from the hip here trying to give you some pointers for debugging.