ShowSuperHidden
, as we discovered, controls whether super-hidden (Hidden + System) files are displayed. As far as I can tell, SuperHidden
controls nothing and its existence is probably a programming error.
Using Process Monitor, I observed reads from and writes to these Registry values. The only interaction with SuperHidden
was a write when the user opened the View tab of the Folder Options dialog. It received a 1 if super-hidden files are displayed, 0 otherwise. It was never read, even when I terminated and restarted Explorer.
Procmon provides the stack that led to a monitored operation (double-click an event and consult the Stack tab), so I examined the DLL files involved using IDA v5.0. The only relevant one with a mention of SuperHidden
was shell32.dll
. The CachedShellState::SaveAdvancedSettings
function issues a Registry write to that value and others in that key, committing the current view settings.
Explorer apparently calls that function before showing the View tab. That's probably done to make sure the Registry is consistent with the current in-memory settings before loading the current state of the View options, though I admit I'm not 100% certain on the reasoning. Anyway, the corresponding shell32.dll
function CachedShellState::_GetAdvancedSettings
issues a read from the correct value, ShowSuperHidden
.
These disassembly listings are from the Windows 7 version of that DLL. In Windows 10, SuperHidden
does not exist in the Registry, and CachedShellState::SaveAdvancedSettings
writes to ShowSuperHidden
.
Therefore, I conclude that when programming the version of that function that comes with Windows 7, a developer mistakenly omitted the Show
in ShowSuperHidden
, but the error was corrected along the way to Windows 10.
For the curious, the Folder Options dialog isn't broken by this error because it consults the ValueName
entry under each setting key here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder
Working out the significance of the other parts of that branch is left as a (fun!) exercise to the reader.
1How did you find it is shell32.dll? Process Monitor shows explorer.exe changes this registry? – Biswapriyo – 2017-08-13T20:49:53.430
2@Biswa Right,
explorer.exe
is the process responsible for the change, but it is code insideshell32.dll
(which Explorer loads) that makes the call. To see DLLs involved, double-click an event and switch to the Stack tab. The frame beforekernel32.dll
orkernelbase.dll
is usually a good one to investigate, but it's not always clear, which is why I checked several DLL files. – Ben N – 2017-08-13T20:55:37.223+1, some great detective work here. Based on this it seems pretty conclusive that the
SuperHidden
key was a mistake. The OCD in me really wishes they'd actually used that key instead ofShowSuperHidden
, just for the sake of naming consistency withHidden
. – Hashim – 2017-08-14T00:32:36.607Very nice +1 and on the other post as well. – Pimp Juice IT – 2017-08-14T01:07:11.863
Why Windows 10 shell32.dll shows a different address of Show SuperHidden? image.
– Biswapriyo – 2017-08-15T13:47:55.427@Biswa Good question! Different compiler/linker versions sometimes lay out the output files differently. Additionally, I think that screenshot is from a 64-bit version, while mine are from 32-bit systems, which will cause addresses and sizes to be different. – Ben N – 2017-08-15T14:06:45.110
2I joined SuperUser to upvote this! You included a number of useful things in addition to SuperHidden: another use of ProcMon, the incredible IDA tool, plus the tips in the linked question. Thank you! – Todd – 2018-10-01T14:33:02.823