LTSC: does it still make sense with NTLite?
- Thread starter 4nt
- Start date
It depends on the programming of the "app" (or .exe or .dll) that accesses the registry. Some will create keys/values if they are not present.
But in this case, as well as with many Windows "tweaks", the default is meant to be not present, instead you alter the value by creating the registry tree above it and then the value.
Most often these "tweaks" came into existence because someone somewhere asked for it (Microsoft's Volume license customers? or some team) and is not meant to be widely known to the "unitiated" mostly because it adds another branch to eventual support efforts (and support costs manpower and money), but most importantly, because it keeps them in control.
That's why you see in the forums, very often, the similar question: "The registry key doesn't exist. What should I do?" Well, you create it, of course.
Registry reads also take two forms, also depending on the programming (the function they call). 1. they stop at the highest branch if nonpresent 2. they ask to read the full path of the key/value directly. In case of (1.) you need to create registry branches one by one until you arrive to the final value that is requested.
But in this case, as well as with many Windows "tweaks", the default is meant to be not present, instead you alter the value by creating the registry tree above it and then the value.
Most often these "tweaks" came into existence because someone somewhere asked for it (Microsoft's Volume license customers? or some team) and is not meant to be widely known to the "unitiated" mostly because it adds another branch to eventual support efforts (and support costs manpower and money), but most importantly, because it keeps them in control.
That's why you see in the forums, very often, the similar question: "The registry key doesn't exist. What should I do?" Well, you create it, of course.
Registry reads also take two forms, also depending on the programming (the function they call). 1. they stop at the highest branch if nonpresent 2. they ask to read the full path of the key/value directly. In case of (1.) you need to create registry branches one by one until you arrive to the final value that is requested.
It's true that some important keys are undocumented, and for internal/special use. Registry is a just a data store for values. Whether Windows or any app bothers to obey a key is entirely up to that app. Ignored keys are silently ignored. Bad keys, of course, can crash a system.
Sometimes the only way to discover relevant keys is by external snooping, by using ProcMon (tracing reg calls) or using a registry snapshot tool to compare before & after copies.
Sometimes a program will recreate the minimum required keys if the original ones are deleted. Other times, they're only created by the installer.
You just have to learn by trying, or find out online. But always, confirm by testing. Sometimes people (even myself) are wrong, because the answer can differ depending on what Windows release you're using.
Sometimes the only way to discover relevant keys is by external snooping, by using ProcMon (tracing reg calls) or using a registry snapshot tool to compare before & after copies.
Sometimes a program will recreate the minimum required keys if the original ones are deleted. Other times, they're only created by the installer.
You just have to learn by trying, or find out online. But always, confirm by testing. Sometimes people (even myself) are wrong, because the answer can differ depending on what Windows release you're using.
Hellbovine
Well-Known Member
Yeah your whole reply makes sense, but Windows has to store the info somewhere for defaults that don't exist, and that's what I'm hoping to find. So as a dirty example, let's say:
[HKLM\blah\blah\blah\tweak]
"DisablePowerSaving"
In our example here this key doesn't exist in regedit by default, and even if you do a search for that key in every single tree you won't find it, but Windows still has to know what the default value is, and then it goes and checks that secret location and uses that fallback value. Where is that secret location though, which has this made up key "DisablePowerSaving" and its default value? I'm gonna try loading that hive Garlin mentioned and see how those keys differ. Does it have the fallback defaults in it for keys that don't exist in regedit, or is that config file literally just the stuff regedit loads when we open that program?
Last edited:
It's hardcoded in the calling .exe or .dll. Hint: use Strings from Sysinternals. I use TotalCommander's search function, which searches ANSI/Unicode/whatever strings in one go, and is reasonably fast to search entire \system32 in few seconds. I have never encountered encrypted or obfuscated reg key names in .dlls, I guess Microsoft doesn't deem them worthy of disguising.
The thing is, it is not stored as full registry path/key/value, but often as separate components. You'd need to debug the .dll/.exe to fully understand it (to run it through a debugger/decompiler). The next best thing is to just monitor calls with ProcMon, of course.
As I said, if it is not documented, we can not know the defaults, but can often conclude from the name what the function is and what does it do.
So true, sometimes with the undocumented keys/values, their mere presence turns on debugging/logging, for example.