Under the registry key:


...there are two well-documented values that pertain to the showing of hidden files and folders in Windows Explorer.

The Hidden key shows hidden files when true, and hides them when false.

The ShowSuperHidden key is generally acknowledged as its equivalent for "super hidden" (i.e. protected/system) files; it shows super-hidden files when true, and hides them when false.

That said, where does the SuperHidden value come in? Its name suggests it would be the natural analogue to the Hidden key, but documentation on it and what it does is non-existent as far as I've been able to tell.

What is the purpose of the SuperHidden value, and how does it differ from ShowSuperHidden?


1 Answer 1


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.

writing SuperHidden in SaveAdvancedSettings

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.

reading ShowSuperHidden in _GetAdvancedSettings

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.

Windows 10 writes to ShowSuperHidden in SaveAdvancedSettings

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:


Working out the significance of the other parts of that branch is left as a (fun!) exercise to the reader.

  • 1
    How did you find it is shell32.dll? Process Monitor shows explorer.exe changes this registry?
    – Biswapriyo
    Aug 13, 2017 at 20:49
  • 2
    @Biswa Right, explorer.exe is the process responsible for the change, but it is code inside shell32.dll (which Explorer loads) that makes the call. To see DLLs involved, double-click an event and switch to the Stack tab. The frame before kernel32.dll or kernelbase.dll is usually a good one to investigate, but it's not always clear, which is why I checked several DLL files.
    – Ben N
    Aug 13, 2017 at 20:55
  • +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 of ShowSuperHidden, just for the sake of naming consistency with Hidden. Aug 14, 2017 at 0:32
  • Very nice +1 and on the other post as well. Aug 14, 2017 at 1:07
  • 2
    I 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
    Oct 1, 2018 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.