locked
Registry Filter Documentation RRS feed

  • Question

  • Can somebody point me to a document specifying how to configure Register Filter. The online help is not descriptive enough.

    This is what I am trying to achieve:

    I want to make sure any registry changes (keys/folders created/deleted/modified) in the path: HKEY_CURRENT_USER\SOFTWARE\[Company Name]\[Product Name], persist between boots, when FBWF is enabled.

    Action: AddListItem/Modify/RemoveListItem (I think the AddListItem is what I need to use based on other posts)

    Id: (What should be this value)

    RegistryRoot: HKLM (that is the only value supported, if I am using Current User then should it be HKCU?)

    RegistryKey: SOFTWARE\[Company Name]\[Product Name]

    Your help is much appreciated.

    Thursday, March 24, 2011 11:46 PM

Answers

  • What do you recommend is the way to make the keys under HKCU persist. As I said I am only interested in keys under the path: HKCU\software\[Company Name]\[Product Name], to persist between reboots.

     

    I just got finished researching this myself. Registry Filter for HKCU/HKU won't work. If you don't open up the entire USER portion of the registry like Sean recommends against, then I'm thinking you might be able to create your own persistent file. I'm just brainstorming without thinking it fully through, but if at logoff you wrote the contents of the key you want persisted to a file at a specific location (the file would be excluded in FBWF) you could then restore it on logon. Not trivial, but also not impossible with registry commands or scripting.

    A side note, I've had the HKEY_CURRENT_USER registry open for over a year on 20 thin client laptops (NTUSER.DAT and ntuser.dat.LOG). I've had a few come in with a corrupted SYSTEM registry file (from memory, c:\windows\system32\config\SYSTEM) which means.. no booting, reimage time. However I don't see the connection to the user registry being opened up. I have had malware write itself into the Run key... :) If I keep them open in the updated image I'm building now, then I'll see if I can reduce permissions to the Run key.

    chris

    [edit] NOTE: I'm using WES 2009 Standard, not 7. I didn't realize which forum I was in when I replied.
    • Edited by cdenesha Tuesday, April 19, 2011 9:19 PM qualify my answer
    • Marked as answer by ulahoti Tuesday, June 21, 2011 6:26 PM
    Tuesday, April 19, 2011 9:12 PM
  • Ulahoti,

    We have two customers that have reg keys, they insist on keeping in HKCU.  The customer wanted the data to persist past reboot.  It has to be tied to a "specific" user since it is HK Current User.

    We addexclusion for NTUSER.DAT and NTUSER.dat.log1, those files live in "C:\Users\YourUser".  Just remember that the key is tied to the Current User.  The exclusion only allows the key to persist for the user you create it for.  If someone else logs in it will not persist for them.  Then add the registry keys something like this:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RegFilter\Parameters\MonitoredKeys\3]
    "ClassKey"="HKCU"
    "FileNameForSaving"="YourProg.rgf"
    "RelativeKeyName"="Software\\Your Program Settings"

    I hope this helps. 


    By adding the write filter exclusion to the NTUSER.DAT and log file in that user's folder, you are already allowing *everything* in that user's HKCU to persist - because those files are where HKCU come from!

    Using Registry Filter is totally unnecessary and is not doing anything in this case.

    chris

    • Marked as answer by ulahoti Tuesday, June 21, 2011 6:25 PM
    Thursday, April 21, 2011 1:36 PM

All replies

  • There are limits to what the Registry Filter can protect. User information is not supported. There is an important note in the online help that mentions this.

    Can you use the generic HKLM\Software\Company Name\product name path?

    ID - any integer value. The idea is to provide a means to seperate entries in the answer file (XML).

    -Sean


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - ProGuide to WES 7, XP Embedded Advanced, WEPOS / POS for .NET Step-by-Step
    Friday, March 25, 2011 11:26 AM
  • Sean,

    Thanks for your reply.

    If I understand your reply correctly, ID essentially means a unique number to identify multiple Registry Filter entries in the List? It has no other use to identify a Registry entry.

    About HKCU registry values that I want to persist between boots, I read somewhere in this forum, that I need to add the following files: NTUSER.DAT and NTUSER.LOG in the hole for FBWF.

    If this is the approach to take, can you tell me where these files are present in the drive. I found the following two locations for these files:

    1. c:\windows\system32\config\systemprofiles

    2. c:\windows\ServiceProfiles

    Let me know your thoughts on this.

     

     

    Friday, March 25, 2011 4:35 PM
  •  

    1. ID - Yes, it is just a unique number. i.e. 1, 2, 3, ...etc. It has nothing to do with.

    2. The NTUSER.DAT file(s) are in the \USER\<..> directories, but I am not a big fan of opening holes in FBWF for registry keys. Corruption is possible, and it might cause system failure.

    -Sean

     


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - ProGuide to WES 7, XP Embedded Advanced, WEPOS / POS for .NET Step-by-Step
    Friday, March 25, 2011 9:25 PM
  • Sean,

    What do you recommend is the way to make the keys under HKCU persist. As I said I am only interested in keys under the path: HKCU\software\[Company Name]\[Product Name], to persist between reboots.

    Thanks,

    Saturday, March 26, 2011 11:29 AM
  • What do you recommend is the way to make the keys under HKCU persist. As I said I am only interested in keys under the path: HKCU\software\[Company Name]\[Product Name], to persist between reboots.

     

    I just got finished researching this myself. Registry Filter for HKCU/HKU won't work. If you don't open up the entire USER portion of the registry like Sean recommends against, then I'm thinking you might be able to create your own persistent file. I'm just brainstorming without thinking it fully through, but if at logoff you wrote the contents of the key you want persisted to a file at a specific location (the file would be excluded in FBWF) you could then restore it on logon. Not trivial, but also not impossible with registry commands or scripting.

    A side note, I've had the HKEY_CURRENT_USER registry open for over a year on 20 thin client laptops (NTUSER.DAT and ntuser.dat.LOG). I've had a few come in with a corrupted SYSTEM registry file (from memory, c:\windows\system32\config\SYSTEM) which means.. no booting, reimage time. However I don't see the connection to the user registry being opened up. I have had malware write itself into the Run key... :) If I keep them open in the updated image I'm building now, then I'll see if I can reduce permissions to the Run key.

    chris

    [edit] NOTE: I'm using WES 2009 Standard, not 7. I didn't realize which forum I was in when I replied.
    • Edited by cdenesha Tuesday, April 19, 2011 9:19 PM qualify my answer
    • Marked as answer by ulahoti Tuesday, June 21, 2011 6:26 PM
    Tuesday, April 19, 2011 9:12 PM
  • Ulahoti,

    We have two customers that have reg keys, they insist on keeping in HKCU.  The customer wanted the data to persist past reboot.  It has to be tied to a "specific" user since it is HK Current User.

    We addexclusion for NTUSER.DAT and NTUSER.dat.log1, those files live in "C:\Users\YourUser".  Just remember that the key is tied to the Current User.  The exclusion only allows the key to persist for the user you create it for.  If someone else logs in it will not persist for them.  Then add the registry keys something like this:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RegFilter\Parameters\MonitoredKeys\3]
    "ClassKey"="HKCU"
    "FileNameForSaving"="YourProg.rgf"
    "RelativeKeyName"="Software\\Your Program Settings"

    I hope this helps. 

    Wednesday, April 20, 2011 10:36 PM
  • Ulahoti,

    We have two customers that have reg keys, they insist on keeping in HKCU.  The customer wanted the data to persist past reboot.  It has to be tied to a "specific" user since it is HK Current User.

    We addexclusion for NTUSER.DAT and NTUSER.dat.log1, those files live in "C:\Users\YourUser".  Just remember that the key is tied to the Current User.  The exclusion only allows the key to persist for the user you create it for.  If someone else logs in it will not persist for them.  Then add the registry keys something like this:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RegFilter\Parameters\MonitoredKeys\3]
    "ClassKey"="HKCU"
    "FileNameForSaving"="YourProg.rgf"
    "RelativeKeyName"="Software\\Your Program Settings"

    I hope this helps. 


    By adding the write filter exclusion to the NTUSER.DAT and log file in that user's folder, you are already allowing *everything* in that user's HKCU to persist - because those files are where HKCU come from!

    Using Registry Filter is totally unnecessary and is not doing anything in this case.

    chris

    • Marked as answer by ulahoti Tuesday, June 21, 2011 6:25 PM
    Thursday, April 21, 2011 1:36 PM