src/utilcode/registrywrapper.cpp

   1 // Licensed to the .NET Foundation under one or more agreements.
   2 // The .NET Foundation licenses this file to you under the MIT license.
   3 // See the LICENSE file in the project root for more information.
   4 //*****************************************************************************
   5 // File: registrywrapper.cpp
   6 //
   7
   8 //
   9 // Wrapper around Win32 Registry Functions allowing redirection of .NET
  10 // Framework root registry location
  11 //
  12 // Notes on Offline Ngen Implementation:
  13 //
  14 // This implementation redirects file accesses to the GAC, NIC, framework directory
  15 // and registry accesses to root store and fusion.
  16 // Essentially, if we open a file or reg key directly from the CLR, we redirect it
  17 // into the mounted VHD specified in the COMPLUS config values.
  18 //
  19 // Terminology:
  20 //  Host Machine - The machine running a copy of windows that mounts a VHD to
  21 //      compile the assemblies within.  This is the build machine in the build lab.
  22 //
  23 //  Target Machine - The VHD that gets mounted inside the host.  We compile
  24 //      native images storing them inside the target.  This is the freshly build
  25 //      copy of windows in the build lab.
  26 //
  27 // The OS itself pulls open all manner of registry keys and files as side-effects
  28 // of our API calls. Here is a list of things the redirection implementation does
  29 // not cover:
  30 //
  31 // - COM
  32 //      We use COM in Ngen to create and communicate with worker processes.  In
  33 //      order to marshal arguments between ngen and worker, mscoree.tlb is loaded.
  34 //      The COM system from the loaded and running OS is used, which means the host
  35 //      machine's mscoree.tlb gets loaded for marshalling arguments for the CLR
  36 //      running on the target machine. In the next release (4.5) the ngen interfaces
  37 //      don't expect to change for existing ngen operations.  If new functionality
  38 //      is added, new interfaces would be added, but existing ones will not be
  39 //      altered since we have a high compat bar with an inplace release.  mscoree.tlb
  40 //      also contains interfaces for mscoree shim and gchost which again we expect to
  41 //      remain compatible in this next product release.  In order to fix this, we will
  42 //      need support from Windows for using the COM system on another copy of Windows.
  43 // - Registry Accesses under
  44 //      - HKLM\software[\Wow6432Node]\policies\microsoft : SQM, Cryptography, MUI, codeidentifiers, appcompat, RPC
  45 //      - HKLM\software[\Wow6432Node]\RPC,OLE,COM and under these keys
  46 //      - HKLM\Software\Microsoft\Cryptography and under
  47 //      - HKLM\Software\Microsoft\SQMClient
  48 //      - HKLM\Software[\Wow6432Node]\Microsoft\Windows\Windows Error Reporting\WMR and under
  49 //
  50 //      These locations are not accessed directly by the CLR, but looked up by Windows
  51 //      as part of other API calls.  It is safer that we are accessing these
  52 //      on the host machine since they correspond with the actively running copy of
  53 //      Windows.  If we could somehow redirect these to the target VM, we would have
  54 //      Windows 7/2K8 OS looking up its config keys from a Win8 registry.  If Windows
  55 //      has made incompatible changes here, such as moving the location or redefining
  56 //      values, we would break.
  57 //  - Accesses from C:\Windows\System32 and C:\Windows\Syswow64 and HKCU
  58 //      HKCU does not contain any .NET Framework settings (Microsoft\.NETFramework
  59 //      is empty).
  60 //      There are various files accessed from C:\Windows\System32 and these are a
  61 //      function of the OS loader.  We load an executable and it automatically
  62 //      pulls in kernel32.dll, for example.  This should not be a problem for running
  63 //      the CLR, since v4.5 will run on Win2K8, and for offline ngen compilation, we
  64 //      will not be using the new Win8 APIs for AppX.  We had considered setting
  65 //      the PATH to point into the target machine's System32 directory, but the
  66 //      Windows team advised us that would break pretty quickly due to Api-sets
  67 //      having their version numbers rev'd and the Win2k8 host machine not having
  68 //      the ability to load them.
  69 //
  70 //
  71 //*****************************************************************************
  72 #include "stdafx.h"
  73 #include "registrywrapper.h"
  74 #include "clrconfig.h"
  75 #include "strsafe.h"
  76