WiX Burn Managed Bootstrapper fails to load - Errror 0x80040150

My managed bootstrapper application as of yesterday fails to run on some machines, with the following error:

[07F4:13CC][2013-12-12T12:20:31]e000: Error 0x80040150: Failed to create the managed bootstrapper application. 
[07F4:13CC][2013-12-12T12:20:31]e000: Error 0x80040150: Failed to create UX.
[07F4:13CC][2013-12-12T12:20:31]e000: Error 0x80040150: Failed to load UX.
[07F4:13CC][2013-12-12T12:20:31]e000: Error 0x80040150: Failed while running
... 
...
[07F4:13CC][2013-12-12T12:20:31]e000: Error 0x80040150: Failed to run per-user mode.

Apparently, 0x80040150 (2147746128) is: REGDB_E_READREGDB: Could not read key from registry

In the event log, I can see

Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards. No user action is required.  

 DETAIL - 
 7 user registry handles leaked from \Registry\User\S-1-5-21-4128267814-1525589554-1895505527-1113_Classes:
Process 4332 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<file>.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES
Process 4332 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<file>.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES
Process 6180 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<folder>\BurnBasedSetupKit.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES
Process 6180 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<folder>\BurnBasedSetupKit.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES
Process 3408 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<folder>\BurnBasedSetupKit.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES
Process 3408 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<folder>\BurnBasedSetupKit.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES
Process 4332 (\Device\HarddiskVolume4\Users\<username>\AppData\Roaming\<companyname>\<product>\<file>.exe) has opened key \REGISTRY\USER\S-1-5-21-4128267814-1525589554-1895505527-1113_CLASSES

It may be pertinent to mention that the BurnBasedSetupKit.exe is invoked by a service using c# code:

Process proc = new Process();
proc.StartInfo.FileName = "BurnBasedSetupKit.exe";
proc.StartInfo.Arguments = string.Format("-s -l {0}", logFileName);
proc.StartInfo.Verb = "runas";
proc.StartInfo.CreateNoWindow = true;
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.ErrorDialog = false;
proc.StartInfo.RedirectStandardOutput = true;    
proc.Start();
proc.WaitForExit();
if (proc.ExitCode != 0)
{
    throw new Exception(string.Format("Setup execution process exited with non-zero ExitCode: {0}", proc.ExitCode.ToString()));
}    

The service runs under a user who is in the local administrators group. The BurnBasedSetupKit.exe could very well be invoked by the service when the machine is running but there is no user logged in. [Note: When the BurnBasedSetupKit.exe kit is invoked interactively, everything works fine.]

I tried upgrading to the latest stable version of WiX toolset, and the same issue still occurs. This only seems to manifest on some machines. There have been no changes in my custom managed bootstrapper codebase which has been working flawlessly for months.

I have confirmed that I don't have the same issue as others who have run into similar errors (here, here, here, here).

Would appreciate if someone could shed some light.

UPDATE

After some trial and error, it appears when the service that starts the setup kit is restarted before the invocation of the setup kit kicks in, from a different process space, this issue does not occur. It is however not quite deterministic.

I have narrowed it down to a combination of two things, not necessarily related: (a) The service leaving orphaned handles to the user registry hive and (b) the windows user profile service proactively killing any user registry hive handles that the service has left open for the bootstrapper to use.

Restarting the service seems to mitigate the issue, I believe by clearing out any orphaned registry handles, before the bootstrapper is invoked. An alternate solution may be to create the process using the native C++ call via P/Invoke and letting the child process inherit handles (the .NET call doesn't seem to allow users to explicitly specify inheritance of handles). This should prevent the user profile service from detecting the registry handles as orphaned and allow the bootstrapper to use the user profile's resources as needed. Further, I also ended up loading the service identity's user profile before the setup kit is invoked. A combination of these steps has solved the problem.