locked
RegUnloadKey - Key is not saved RRS feed

  • Question

  • I have created my own deployment program that runs on WinPE. When booting with it, it will configure the hard drive and deploy my custom wim of Embedded Standard 7. It works great. Only issue I have had is with loading, customizing the registry, then closing it. I am using .NET 4.0 with VB. When the program finishes deploying the WIM, it loads the software registry hive from the deployed OS into the WinPE registry. Then it adds some entries into the RunOnce and OEMInformation keys. Once it has confirmed the entries it invokes RegUnloadKey to close it. Problem I am having is that is does not always save the hive to the hard drive.

    I have a second step that will reload the hive and check that the entries are there. It sees they are not and thus fails the operation. It appears that when RegUnloadKey runs, it closes the loaded hive, but does not save it. Weird thing is that is does not always fail and on some of my older hardware it works all of the time.

    I am using SSD's. This process did work on older hardware using the Win7 and Win8 versions of WinPE. I am now using the Win10 version of WinPE as I am moving to newer hardware and preparing to move to Win10 LTSB.

    One thought was that perhaps there is a write cache issue where the hive is not getting flushed to the SSD after RegUnloadKey. But I cannot find any information on how to force flush the write cache in WinPE.

    Any ideas would be greatly appreciated.

    Friday, June 2, 2017 1:37 PM

All replies

  •  Did you check the return values of all the win32 api functions you are using to see if one or the other along the way is returning an error code instead of 0 which is ERROR_SUCCESS that indicates no errors occurred.  That may give you an idea of what and where the problem is occurring.

     Below is a good Vb.Net signature for the function. Most any newer OS is most likely going to use the unicode signature "W" instead of the ANSI "A" signature.  It requires you to import the "System.Runtime.InteropServices" namespace at the top of your code.  I would also check to make sure all your other win32 api function signatures are correct too.

        <DllImport("advapi32.dll", EntryPoint:="RegUnLoadKeyW")>
        Public Shared Function RegUnLoadKeyW(ByVal hKey As IntPtr, <MarshalAs(UnmanagedType.LPWStr)> ByVal lpSubKey As String) As Integer
        End Function
    
     

     Here is a link to the first page of the System Error Codes which most of the Regxxx functions return if they do not succeed.  Look there to see what the error description is if you get one.

    System Error Codes

    Msdn Document - RegUnLoadKey function



    If you say it can`t be done then i`ll try it

    Friday, June 2, 2017 9:21 PM
  • The problem I am having is that when I unload the hive it does not always save my changes. I check the return value and there is no issue. When I open the hive up again all of my changes are gone. This is crazy. It has worked for many years and now in the last five months it has had problems. If it did not work every time then I would have a clear issue, but fails 3 of 5 times and there are never any errors. Loading or Unloading the hive.
    Thursday, June 8, 2017 9:47 PM
  • One thought was that perhaps there is a write cache issue where the hive is not getting flushed to the SSD after RegUnloadKey. But I cannot find any information on how to force flush the write cache in WinPE.

    Any ideas would be greatly appreciated.

    Hi VanAwful,

    About forcing flush the write cache in WinPE, there is the FlushFileBuffers call, which takes a file handle as argument.

    Note: FlushFileBuffers does not need administrative privileges; it does only if the handle passed to it is the handle for a volume, not for a single file.

    https://stackoverflow.com/questions/173560/flush-disk-write-cache

    Best Regards,

    Cherry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, June 13, 2017 8:05 AM