4

In the context of a generalized .NET-based component, which can be hosted in a variety of scenarios - i.e., 64 bit or not, interactive process or not, I need to write to the registry in an area that's subject to UAC virtualisation. However, I want to prevent such access from being virtualized in order that each execution is not subject to the vagaries of the present context (i.e., don't want to have one reading from HKLM as it has a manifest and the other from HKCU..VirtualStore because it doesnt).

In other words, I'm looking for something analogous to KEY_WOW64_64KEY or reg.exe REG_KEY_DONT_VIRTUALIZE to indicate that I dont want to be virtualised under any circumstances. Or is there some form of canonicalization-related syntax I can use to force it a la the way you specify a >260 char filename?

I'm fine with the code failing if the executing user doesnt have appropriate permissions on the registry key in question.

This question is strongly related to this question on detecting registry virtualization, but detecting definitely isnt enough in this context.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
  • If `REG_KEY_DONT_VIRTUALIZE` solves your problem: why not use it? If you are hosted in some application that **needs** virtualization, you can still have **your** registry access not virtualized. – Ian Boyd Apr 02 '21 at 20:42
  • Struggling to page this back in after 12y but AIUI that [`REG_KEY_DONT_VIRTUALIZE`] flag would need to be placed on the key; I'm (or, I was!) writing code within the context of a generic library that can be run in any context; it would not have permissions to apply such flags, in other words the ask is for a programmatic way to signal I want to _opt out because my code is considering that_ (like putting the manifest on the exe would signal if I was writing and/or in full control of an app). – Ruben Bartelink Apr 02 '21 at 22:38

1 Answers1

0

Applications with a UAC-aware manifest, whether specifying asInvoker or requireAdministrator, are not virtualized. If you're ok with it failing, go with asInvoker.

Kate Gregory
  • 18,808
  • 8
  • 56
  • 85
  • Hi Kate, thanks for the answer. Unfortunately the ["In the context of a generalized component"] proviso in the question is there in order to indicate that this is outside of my control, hence my question. – Ruben Bartelink Jun 25 '10 at 08:14
  • But I bet you have answers to lots of my other open esoteric questions just waiting to jump out - if your DNR eps are anything to go by :D – Ruben Bartelink Jun 25 '10 at 08:23
  • Oh dear, you might have to head into COM elevation moniker territory. I'm not sure off the top of my head what the .NET equivalent is, if there is one. – Kate Gregory Jun 25 '10 at 11:09
  • 1
    That sounds like it's probably the reason some of my apps run differently when set to run as admin mode. Any idea why Microsoft does all this registry redirection nonsense? What problem were they trying to avoid? For that matter, why is the 32-bit Program Files renamed and the 64-bit one called "Program Files"? I'm just flabbergasted by Microsoft's design decisions. – supercat Dec 17 '10 at 23:52
  • 1
    32/64 virtualization and admin/non-admin virtualization are different, but in both cases the deal is that old apps, unaware the world has changed, are asking for something that isn't where they think it is or they aren't allowed to get. If not labelled "hey, I know it's a brave new world and I know what I want", they are given something close to what they wanted on the grounds it's better than crashing. For some apps, it is. If you don't like what you get, stop settling for the redirected/virtualized/best we can do in the new world substitute, and start asking for what you really want. – Kate Gregory Dec 18 '10 at 05:11