Loading article…
Windowsレジストリは、 Microsoft Windowsオペレーティングシステムおよびレジストリを使用するアプリケーションのための低レベル設定を格納する階層型データベースです。カーネル、デバイスドライバ、サービス、セキュリティアカウントマネージャ、およびユーザーインターフェイスはすべてレジストリを使用できます。レジストリは、システムパフォーマンスをプロファイリングするためのカウンタへのアクセスも提供します。
つまり、レジストリ（Windowsレジストリ）には、Microsoft Windowsオペレーティングシステムのすべてのバージョンにインストールされているプログラムやハードウェアに関する情報、設定、オプション、その他の値が格納されています。たとえば、プログラムがインストールされると、プログラムの場所、バージョン、起動方法などの設定を含む新しいサブキーがWindowsレジストリに追加されます。
Windows 3.1で導入された当初、Windows レジストリは主にCOMベースのコンポーネントの構成情報を格納していました。Windows 95とWindows NT では、さまざまな場所に保存されていた多数のINI ファイルの情報を合理化および一元化するために、その用途が拡張されました。 [ 1 ] [ 2 ] Windows アプリケーションが Windows レジストリを使用することは必須ではありません。たとえば、.NET Frameworkアプリケーションは構成にXMLファイルを使用し、ポータブル アプリケーションは通常、構成ファイルを実行可能ファイルとともに保持します。
Windows レジストリが登場する以前は、.INI ファイルは各プログラムの設定をテキスト ファイルまたはバイナリ ファイルとして保存していましたが、多くの場合、共有場所に配置されており、マルチ ユーザー シナリオではユーザー固有の設定を提供できませんでした。これに対し、Windows レジストリは、すべてのアプリケーション設定を 1 つの論理リポジトリ (ただし、複数の個別のファイルにも) に標準化された形式で保存します。Microsoft によると、これは .INI ファイルに比べていくつかの利点があります。[ 2 ] [ 3 ]バイナリ フォーマットではファイルの解析がはるかに効率的に行われるため、テキスト INI ファイルよりも高速に読み書きできます。さらに、.INI ファイルに保存されるテキスト情報とは異なり、レジストリには厳密に型指定されたデータを保存できます。これは、組み込みの Windows レジストリ エディターであるregedit.exeを使用してキーを手動で編集する場合に利点となります。ユーザー ベースのレジストリ設定は、読み取り専用のシステム ロケーションではなく、ユーザー固有のパスから読み込まれるため、レジストリでは複数のユーザーが同じマシンを共有でき、権限の低いユーザーでもプログラムが動作することができます。レジストリはネットワーク接続を介してリモート管理/サポートのためにアクセスでき、スクリプトなどからもアクセスできるため、バックアップと復元も簡素化されます。ただし、リモートレジストリサービスが実行されており、ファイアウォールルールで許可されていることが条件となります。
レジストリはデータベースであるため、アトミック更新などの機能により、システムの整合性が向上します。2つのプロセスが同時に同じレジストリ値を更新しようとした場合、一方のプロセスの変更が他方のプロセスの変更よりも優先され、データの全体的な一貫性が維持されます。.INI ファイルに変更が加えられる場合、このような競合状態が発生すると、どちらの更新も一致しない不整合なデータが発生する可能性があります。Windows Vista 以降のオペレーティングシステムでは、カーネルトランザクションマネージャを使用してレジストリへのトランザクション更新が提供され、従来のコミット/アボートセマンティクスで複数のキーまたは値の変更にわたってアトミック性の保証が拡張されます。（ただし、NTFS もファイルシステムに対して同様のサポートを提供しているため、理論的には従来の構成ファイルでも同様の保証が得られることに注意してください。）
レジストリは、キーと値の2つの基本要素で構成されています。レジストリキーは、フォルダに似たコンテナオブジェクトです。レジストリ値は、ファイルに似た非コンテナオブジェクトです。キーには値とサブキーを含めることができます。キーは、Windowsのパス名に似た構文で参照され、バックスラッシュを使用して階層レベルを示します。キー名は大文字と小文字を区別せず、バックスラッシュは使用しないでください。
レジストリ キーの階層構造には、カーネルが保存された「ハイブ」からプリロードしたレジストリ キーの内容、または別のルート キー内のサブキーの内容にマッピングされた既知のルート キー ハンドル (匿名ですが、実効値は定数の数値ハンドルです)、あるいはそのサブキーと値へのアクセスを提供する登録済みのサービスまたは DLL にマッピングされたルート キー ハンドルからのみアクセスできます。
例えば、HKEY は、 HKEY_LOCAL_MACHINEルートキーのサブキー「Software」のサブキー「Microsoft」のサブキー「Windows」を指します。
定義済みのルートキーは 7 つあり、従来は Win32 API で定義されている定数ハンドルに従って命名されていましたが、アプリケーションによっては同義の略語で命名されていました。[ 4 ]
Windows の他のファイルやサービスと同様に、すべてのレジストリ キーは、ユーザー権限、アプリケーションが取得したセキュリティ トークン、またはシステムによって適用されるシステム セキュリティ ポリシーに応じて、アクセス制御リスト(ACL) によって制限される場合があります (これらの制限は、システム自体によって事前に定義され、ローカル システム管理者またはドメイン管理者によって構成される場合があります)。異なるユーザー、プログラム、サービス、またはリモート システムでは、同じルート キーから階層の一部または異なる階層のみを参照できる場合があります。
レジストリ値は、キーに格納される名前とデータのペアです。レジストリ値は、レジストリキーとは別に参照されます。レジストリキーに格納される各レジストリ値には、大文字と小文字を区別しない一意の名前が付けられます。レジストリ値を照会および操作するWindows API関数は、親キーを識別するキー パスまたはハンドルとは別に値名を取得します。レジストリ値の名前にはバックスラッシュを含めることができますが、そうすると、一部の従来の Windows レジストリ API 関数 (Win32 では使用が非推奨) を使用する際に、キー パスとの区別が難しくなります。
この用語はやや誤解を招く恐れがあります。各レジストリ キーは連想配列に似ており、標準的な用語では各レジストリ値の名前部分を「キー」と呼びます。この用語は、レジストリ キーに任意の名前/データ ペアを含めることはできず、名前のない値 (文字列でなければならない) を 1 つだけ含む Windows 3 の 16 ビット レジストリの名残です。この意味で、Windows 3 レジストリは単一の連想配列のようなもので、キー (「レジストリ キー」と「連想配列キー」の両方の意味で) が階層を形成し、レジストリ値はすべて文字列でした。32 ビット レジストリが作成されると、キーごとに複数の名前付き値を作成する機能が追加され、名前の意味がやや歪められました。[ 6 ]以前の動作との互換性のために、各レジストリ キーには「デフォルト」値があり、その名前は空の文字列です。
各値は可変長および可変エンコーディングの任意のデータを格納できますが、そのデータは、このデータの解析方法を定義する記号型（数値定数として定義）に関連付けられています。標準型は次のとおりです。[ 7 ]
階層型データベースのルートレベルのキーは、一般的にWindows API定義で命名され、すべてHKEY [ 2 ]で始まります。これらはしばしば「HK」で始まる3文字または4文字の短い名前に省略されます（例：HKCU、HKLM）。技術的には、これらは特定のキーへの事前定義されたハンドル（既知の定数値を持つ）であり、メモリに保持されるか、ローカルファイルシステムに格納され、起動時にシステムカーネルによってロードされ、ローカルシステムで実行されているすべてのプロセス間で（さまざまなアクセス権限で）共有されるハイブファイルに格納されるか、ユーザーがシステムにログオンしたときにユーザーセッションで開始されたすべてのプロセスにロードされ、マッピングされます。
HKEY_LOCAL_MACHINE (ローカル マシン固有の構成データ) ノードとHKEY_CURRENT_USER (ユーザー固有の構成データ) ノードは互いに似た構造になっています。ユーザー アプリケーションは通常、まず HKEY_CURRENT_USER\Software\Vendor's name\Application's name\Version\Setting name で設定を探し、見つからない場合は、代わりに HKEY_LOCAL_MACHINE キーの下の同じ場所を探します。ただし、管理者によって強制されるポリシー設定の場合は、HKLM がHKCUよりも優先される可能性があるため、逆のことが適用される場合があります。Windowsロゴ プログラムには、さまざまな種類のユーザー データをどこに保存できるか、また、アプリケーションを使用するために管理者レベルのアクセスが必要ないように最小権限の概念に従う必要があるという特定の要件があります。[ a ] [ 10 ]
HKLMと略されるHKEY_LOCAL_MACHINE は、ローカル コンピューター固有の設定を格納します。[ 11 ]
HKLMで指定されるキーは、実際にはディスクには保存されず、他のすべてのサブキーをマッピングするためにシステム カーネルによってメモリに保持されます。アプリケーションは追加のサブキーを作成することはできません。Windows NT では、このキーにはSAM、SECURITY、SYSTEM、SOFTWAREの 4 つのサブキーが含まれており、これらは%SystemRoot%\System32\config\フォルダーにあるそれぞれのファイル内で起動時にロードされます。5 番目のサブキーであるHARDWAREは揮発性で動的に作成されるため、ファイルには保存されません (現在検出されているすべてのプラグアンドプレイ デバイスの表示を公開します)。Windows Vista 以降では、6 番目のサブキーと 7 番目のサブキーであるCOMPONENTSとBCDは、カーネルによってオンデマンドでメモリにマッピングされ、%SystemRoot%\System32\config\COMPONENTSまたはシステム パーティションのブート構成データ\boot\BCDからロードされます。
レジストリは統合された階層型データベースとして提示されているが、レジストリのブランチは実際にはハイブと呼ばれる複数のディスクファイルに格納されている。[ 17 ]（ハイブという言葉は内輪ネタである。）[ 18 ]
一部のハイブは揮発性であり、ディスクには一切保存されません。その例として、HKLM\HARDWAREから始まるブランチのハイブが挙げられます。このハイブにはシステムハードウェアに関する情報が記録され、システムが起動してハードウェア検出を実行するたびに作成されます。
システム上のユーザーごとの設定は、ユーザーごとにハイブ（ディスクファイル）に保存されます。ユーザーがログインすると、システムはHKEY_USERSの下にあるユーザーハイブを読み込み、HKCUのシンボリック参照を現在のユーザーを指すように設定します。これにより、アプリケーションは現在のユーザーの設定をHKCUの下に暗黙的に保存/取得できるようになります。
すべてのハイブが一度にロードされるわけではありません。起動時には最小限のハイブのみがロードされ、その後は、オペレーティングシステムの初期化時、ユーザーのログイン時、またはアプリケーションによって明示的にハイブがロードされるたびに、ハイブがロードされます。
レジストリは物理的には複数のファイルに格納されますが、これらのファイルは通常、レジストリ内のデータを操作するために使用されるユーザーモード API から難読化されています。Windows のバージョンによって、これらのファイルとその場所は異なりますが、すべてローカル マシン上にあります。Windows NT のシステム レジストリ ファイルの場所は%SystemRoot%\System32\config\です。ユーザー固有のHKEY_CURRENT_USERユーザー レジストリ ハイブは、ユーザー プロファイル内のNtuser.datに格納されます。これはユーザーごとに 1 つあります。ユーザーがローミング プロファイルを持っている場合、このファイルはログアウト時とログイン時にそれぞれサーバーとの間でコピーされます。UsrClass.dat という名前の 2 番目のユーザー固有のレジストリ ファイルには COM レジストリ エントリが含まれており、デフォルトではローミングされません。
Windows NT システムでは、レジストリはバイナリ ファイル形式で保存され、これらのオペレーティングシステムのレジストリ エディターによってエクスポート、ロード、アンロードできます。次のシステム レジストリ ファイルは、%SystemRoot%\System32\config\に保存されます。
各ユーザーのプロファイルフォルダには、以下のファイルが保存されています。
Windows 2000、Server 2003、および Windows XP では、ファイル関連付けと COM 情報のために、次の追加のユーザー固有ファイルが使用されます。
Windows Vista以降では、パスが次のように変更されました。
Windows 2000 はレジストリ ハイブ ( .ALT ) の代替コピーを保持し、破損が検出されるとそれに切り替えようとします。[ 20 ] Windows XP および Windows Server 2003 ではSystem.altハイブは保持されません。これは、これらのバージョンの Windows のNTLDRがSystem.logファイルを処理して、シャットダウンまたはクラッシュ中に不整合になった System ハイブを最新の状態にできるためです。さらに、%SystemRoot%\Repairフォルダーには、インストール後および Windows の最初の正常な起動後に作成されたシステムのレジストリ ハイブのコピーが含まれています。
各レジストリ データ ファイルには、トランザクション ログとして機能する「.log」拡張子の関連ファイルがあり、中断された更新が次回の起動時に完了できるようにするために使用されます。[ 21 ]内部的には、レジストリ ファイルは「セル」のコレクションを含む 4 kBの「ビン」 に分割されています。[ 21 ]
レジストリ ファイルは%WINDIR%にUSER.DATとSYSTEM.DATという名前で保存され、Windows ME ではCLASSES.DATが追加されます。また、各ユーザー プロファイル (プロファイルが有効になっている場合) には、%WINDIR%\Profiles\ <ユーザー名> \のユーザー プロファイル ディレクトリにある独自のUSER.DATファイルがあります。
唯一のレジストリファイルはREG.DATという名前で、 %WINDIR%に保存されています。
レジストリファイルにアクセスするには、以下のいずれかの方法でデバイスを特別なモードに設定する必要があります。
上記の方法のいずれかが機能した場合、デバイスのレジストリファイルは{Phone}\EFIESP\Windows\System32\configにあります。
レジストリには、オペレーティングシステム、インストールされているアプリケーション、および各ユーザーとアプリケーションの個別の設定に関する重要な構成情報が含まれています。レジストリ内のオペレーティングシステム構成を不用意に変更すると、取り返しのつかない損傷を引き起こす可能性があるため、通常はインストール/構成および削除中にレジストリ データベースに変更を加えるのはインストーラ プログラムのみです。ユーザーがレジストリを手動で編集する場合は、変更前にレジストリのバックアップを実行することを Microsoft は推奨しています。[ 22 ]コントロール パネルからプログラムを削除しても、完全に削除されない場合があり、見つからないプログラムへの参照によってエラーや不具合が発生した場合は、プログラム ファイルなどのディレクトリ内を手動で確認する必要があるかもしれません。その後、ユーザーはレジストリ内のアンインストールされたプログラムへの参照を手動で削除する必要があるかもしれません。これは通常、RegEdit.exeを使用して行います。[ 23 ]レジストリの編集は、Windows 固有の問題に対処する際に必要になる場合があります。たとえば、ドメインへのログオン時の問題は、レジストリを編集することで解決できます。[ 24 ]
Windowsレジストリは、 RegEdit.exeなどのプログラムを使用して手動で編集できますが、これらのツールでは、最終更新日などのレジストリのメタデータの一部は表示されません。
3.1/95シリーズのオペレーティングシステムのレジストリエディタはRegEdit.exe、Windows NTではRegEdt32.exeです。これらの機能はWindows XPで統合されています。RegEdit.exeと同様のオプションツールやサードパーティ製ツールは、多くのWindows CEバージョンで利用可能です。
レジストリエディターを使用すると、ユーザーは次の機能を実行できます。
.REGファイル（登録エントリとも呼ばれる）は、 INIベースの構文を使用してレジストリの一部をエクスポートおよびインポートするための、テキストベースの人間が読みやすいファイルです。.REGファイルには主に2つのバージョンがあります。
Windows 9x 形式の.REGファイルは、Windows 2000 以降でインポートできます。[ 26 ]これらの後継システムでは、.REGファイルを Windows 9x/NT 形式でエクスポートすることもできます。
データは、次の構文を使用して.REGファイルに保存されます。 [ 26 ]
[<Hive名>\<キー名>\<サブキー名>] "値名" = <値の型>:<値データ>キーのデフォルト値は、「値名」の代わりに「@」を使用することで編集できます。
[<Hive名>\<キー名>\<サブキー名>] @ = <値の型>:<値のデータ>文字列値には<値型>は必要ありません(例を参照) が、バックスラッシュ( \ ) は二重バックスラッシュ ( \\ ) として、引用符 ( " ) はバックスラッシュ引用符 ( \" )として記述する必要があります。 (エスケープの要件は完全に一貫しているわけではありません。エスケープされていない先頭のバックスラッシュを含む文字列を含むファイルが存在し、システムはそれをインポート用に受け入れます。) [ 27 ]
例えば、HKLM\SOFTWARE\Foobarキーに「値 A」、「値 B」などの値を追加するには、次のようにします。
Windowsレジストリエディター バージョン5.00 [ HKEY_LOCAL_MACHINE \SOFTWARE\Foobar] "値 A" = "<エスケープ文字を含む文字列値データ>" "値 B" = hex:<バイナリデータ (カンマ区切りの 16 進数値のリスト)> "値 C" = dword:<DWORD 値整数> "値 D" = hex(0):<REG_NONE (カンマ区切りの 16 進数値のリスト)> "値 E" = hex(1):<REG_SZ (UTF-16LE NULL 終端文字列を表す 16 進数値のカンマ区切りリスト)> "値 F" = hex(2):<展開可能な文字列値データ (UTF-16LE NULL 終端文字列を表す 16 進数値のカンマ区切りリスト)> "値 G" = hex(3):<バイナリデータ (カンマ区切りの 16 進数値のリスト) 16進数値）> ; 「値 B」に等しい「値 H」= hex(4):<DWORD 値 (リトルエンディアンのバイト順で、カンマ区切りの 4 つの 16 進数値のリスト)> 「値 I」= hex(5):<DWORD 値 (ビッグエンディアンのバイト順で、カンマ区切りの 4 つの 16 進数値のリスト)> 「値 J」= hex(7):<マルチ ストリング値データ (UTF-16LE NULL 終端文字列を表す 16 進数値のカンマ区切りリスト)> 「値 K」= hex(8):<REG_RESOURCE_LIST (16 進数値のカンマ区切りリスト)> 「値 L」= hex(a):<REG_RESOURCE_REQUIREMENTS_LIST (16 進数値のカンマ区切りリスト)> 「値 M」= hex(b):<QWORD 値 (カンマ区切りの8つの16進数値のリスト（リトルエンディアンバイト順）>.REGファイルのデータは、これらのファイルをダブルクリックするか、コマンドラインで /s スイッチを使用することで、レジストリに追加/マージできます。REGファイルは、レジストリデータの削除にも使用できます。
キー（およびすべてのサブキー、値、データ）を削除するには、キー名の前にマイナス記号（-）を付ける必要があります。[ 26 ]
例えば、HKLM\SOFTWARE\Foobarキー (およびすべてのサブキー、値、データ) を削除するには、
[ - HKEY_LOCAL_MACHINE \SOFTWARE\Foobar]値（およびそのデータ）を削除するには、削除する値の等号の後にマイナス記号（ - ）を付ける必要があります（ {{{1}}}）。[ 26 ]
例えば、HKLM\SOFTWARE\Foobarキーから「値 A」と「値 B」の値（およびそれらのデータ）のみを削除するには、次のようにします。
[ HKEY_LOCAL_MACHINE \SOFTWARE\Foobar] "値 A" =- "値 B" =-キーHKLM\SOFTWARE\Foobarのデフォルト値（およびそのデータ）のみを削除するには：
[ HKEY_LOCAL_MACHINE \SOFTWARE\Foobar] @ =-セミコロンで始まる行はコメントとみなされます。
; これはコメントです。これは .reg ファイルの任意の場所に配置できます。[ HKEY_LOCAL_MACHINE \SOFTWARE\Foobar] "値" = "例の文字列"Windowsのグループポリシーは、ポリシーに基づいて複数のマシンまたは個々のユーザーのレジストリキーを変更できます。ポリシーがマシンまたはマシンの個々のユーザーに対して初めて有効になると、ポリシーの一部として指定されたレジストリ設定がマシンまたはユーザーの設定に適用されます。
Windows は更新されたポリシーも定期的に探し、適用します。通常は 90 分ごとです。[ 28 ]
ポリシーは、その適用範囲によって、どのマシンとユーザーにポリシーを適用するかを定義します。マシンまたはユーザーがポリシーの適用範囲内にあるかどうかは、組織ディレクトリ内のマシンまたはユーザーアカウントの場所、特定のユーザーまたはマシンアカウント、あるいはセキュリティグループに基づいてフィルタリングできる一連のルールによって定義されます。Windows Management Instrumentation式を使用すると、より高度なルールを設定できます。このようなルールでは、コンピューターのベンダー名、CPU アーキテクチャ、インストールされているソフトウェア、接続されているネットワークなどのプロパティに基づいてフィルタリングできます。
例えば、管理者は、経理部門のマシン用にレジストリ設定のセットを設定したポリシーと、来客エリアのキオスク端末用に別の（ロックダウン）レジストリ設定のセットを設定したポリシーを作成できます。マシンが1つのスコープから別のスコープに移動された場合（例えば、名前の変更や別の組織単位への移動など）、適切なポリシーが自動的に適用されます。ポリシーが変更されると、そのポリシーが現在スコープ内にあるすべてのマシンに自動的に再適用されます。
このポリシーは、設定の選択と変更を行うためのユーザーインターフェースを提供する複数の管理テンプレートを通じて編集されます。管理テンプレートのセットは拡張可能であり、このようなリモート管理をサポートするソフトウェアパッケージは、独自のテンプレートを登録できます。
レジストリは、コマンドラインからさまざまな方法で操作できます。Reg.exeおよびRegIni.exeユーティリティツールは、Windows XP 以降のバージョンの Windows に含まれています。旧バージョンの Windows の場合は、リソースキット CD または Windows のインストール CD にこれらのツールが付属しています。
また、以下のコマンドを使用してコマンドラインから.REGファイルをインポートすることもできます。
RegEdit.exe /sファイル
/s は、ファイルがレジストリにサイレントマージされることを意味します。/s パラメーターを省略すると、操作の確認を求められます。Windows 98、Windows 95、および少なくとも一部の Windows XP 構成では、/sスイッチを使用すると、管理者がレジストリを無効にする設定をRegEdit.exeが無視します。/sスイッチを使用すると、操作が失敗した場合にRegEdit.exe は適切な戻りコードを返しません。これは、 Reg.exe が返す場合とは異なります。
RegEdit.exe /eファイル
V5 形式のレジストリ全体を UNICODE .REGファイルにエクスポートしますが、
RegEdit.exe /e file HKEY_CLASSES_ROOT[\ <キー> ] RegEdit.exe /e file HKEY_CURRENT_CONFIG[\ <キー> ] RegEdit.exe /e file HKEY_CURRENT_USER[\ <キー> ] RegEdit.exe /e file HKEY_LOCAL_MACHINE[\ <キー> ] RegEdit.exe /e file HKEY_USERS[\ <キー> ]
指定された（サブ）キー（スペースが含まれている場合は引用符で囲む必要があります）のみをエクスポートします。
RegEdit.exe /aファイル
レジストリ全体をV4形式でANSI .REGファイルにエクスポートします。
RegEdit.exe /a file <キー>
指定された（サブ）キー（スペースが含まれる場合は引用符で囲む必要があります）のみをエクスポートします。
Reg.exeを使用することも可能です。以下は、レジストリ値 Version の値を表示する例です。
Reg.exe QUERY HKLM\Software\Microsoft\ResKit /v バージョン その他のコマンドラインオプションとしては、VBScriptまたはJScriptとCScript、WMIまたはWMIC.exe、およびWindows PowerShellを組み合わせたものがあります。
レジストリのアクセス許可は、 RegIni.exeと{{{1}}}ツールを使用してコマンドラインから操作できます。たとえば、HKEY_LOCAL_MACHINE\SOFTWAREキーのアクセス許可は、次のように表示できます。
SubInACL.exe /keyreg HKEY_LOCAL_MACHINE\SOFTWARE /display 
Windows PowerShellには、レジストリをファイルシステムと同様の場所タイプとして表示するレジストリプロバイダが付属しています。ファイルシステム内のファイルやディレクトリを操作するために使用されるコマンドと同じコマンドを使用して、レジストリのキーや値を操作できます。[ 29 ]
ファイルシステムと同様に、PowerShell は、デフォルトでコマンドが動作するコンテキストを定義する現在の場所の概念を使用します。Get -ChildItem (エイリアスls、dir、またはgciからも使用可能) は、現在の場所の子キーを取得します。Set -Location (またはエイリアスcd ) コマンドを使用すると、現在の場所をレジストリの別のキーに変更できます。[ 29 ]アイテムの名前を変更したり、アイテムを削除したり、新しいアイテムを作成したり、アイテムまたはプロパティの内容を設定したりするコマンドを使用して、キーの名前を変更したり、キーまたはサブツリー全体を削除したり、値を変更したりできます。
PowerShell スクリプト ファイルを使用すると、管理者は実行時にレジストリに変更を加えるスクリプトを作成できます。このようなスクリプトは、個々のマシンで実行できる管理者に配布できます。PowerShell レジストリ プロバイダーはトランザクションをサポートしており、レジストリへの複数の変更を単一のアトミック トランザクションにまとめることができます。アトミック トランザクションは、すべての変更がデータベースにコミットされるか、スクリプトが失敗した場合は変更がデータベースにコミットされないことを保証します。[ 29 ] [ 30 ]
レジストリは、Advanced Windows 32 Base API Library ( advapi32.dll )の API を介して編集できます。[ 31 ]レジストリ API 関数の一覧:
多くのプログラミング言語には、基盤となる Windows API をラップしてプログラムがレジストリに設定を保存できるようにする組み込みのランタイム ライブラリ関数またはクラスが用意されています (たとえば、 VB.NETおよびC#のMicrosoft.Win32.Registry、またはDelphiおよびFree PascalのTRegistry )。Visual Basic 6のようなCOM対応アプリケーションは、WSH WScript.Shellオブジェクトを使用できます。別の方法として、コードから実行してWindows Resource Kit Tool、 Reg.exe を使用する方法もありますが[ 32 ]、これはプログラミングの慣習としては好ましくないと考えられています。
同様に、Perl ( Win32::TieRegistryを使用)、Python (winreg を使用)、Tcl (レジストリ パッケージにバンドルされています)、[ 33 ] Windows PowerShellおよびWindows Scripting Hostなどのスクリプト言語も、スクリプトからレジストリを編集できます。
Windows Driver Kitから入手できるoffreg.dll [ 34 ]ファイルは、advapi32.dll が提供するものと同様に、現在ロードされていないレジストリ ハイブの作成と操作のための API のセットを提供します。
Windows PEまたはLinux（後者の場合はオープンソースツールを使用）から、オフラインシステムのレジストリ（ハイブ）を編集することも可能です。
登録不要のCOMが導入される以前は、開発者は、オブジェクトが動作するために必要なレジストリ構成を実行するために、プロセス内バイナリとプロセス外バイナリに初期化コードを追加することが推奨されていました。 .DLL ファイルや .OCX ファイルなどのプロセス内バイナリの場合、モジュールは通常、インストール プログラムから呼び出すか、Regsvr32.exe などのユーティリティを使用して手動で呼び出すことができる DllInstall() という関数をエクスポートしていました[ 35 ]。プロセス外バイナリは通常、必要なレジストリ設定を作成または削除するコマンドライン引数 /Regserver と /Unregserver をサポートしています [ 37 ]。DLL Hellの問題が原因 で壊れた COM アプリケーションは、インストール プログラムを再実行することなく、RegSvr32.exe または /RegServer スイッチを使用して修復できることがよくあります[ 38 ] 。
Windows は、ユーザー モード アプリケーションが特定のレジストリ キーが変更された場合に通知イベントを受け取るように登録できる API を公開しています。[ 39 ] また、カーネル モード アプリケーションが他のアプリケーションによって行われたレジストリ呼び出しをフィルタリングおよび変更できるようにする API も利用可能です。[ 40 ]
Windows は、リモート レジストリ サービスが実行され、正しく構成され、ネットワーク トラフィックがファイアウォールで保護されていない場合、 RegConnectRegistry関数[ 41 ]を介して別のコンピューターのレジストリへのリモート アクセスもサポートしています。[ 42 ]
Windows NT の各レジストリキーには、関連付けられたセキュリティ記述子があります。セキュリティ記述子には、アクセス制御リスト (ACL)が含まれており、どのユーザーグループまたは個々のユーザーにアクセス許可が付与または拒否されるかが記述されています。レジストリアクセス許可のセットには、ユーザーまたはユーザーグループに対して明示的に許可または拒否できる 10 個の権限/アクセス許可が含まれています。
オペレーティングシステム内の他のセキュリティ保護可能なオブジェクトと同様に、セキュリティ記述子上の個々のアクセス制御エントリ（ACE）は明示的に指定することも、親オブジェクトから継承することもできます。[ 43 ]
Windows リソース保護は、 Windows Vista以降のバージョンの Windows の機能であり、セキュリティを使用して管理者やシステムが一部の機密キーへの書き込みアクセスを拒否することで、マルウェアや偶発的な変更からシステムの整合性を保護します。[ 44 ]
セキュリティ記述子の特別な ACE を使用すると、レジストリ キーとサブキーの強制的な整合性制御を実装することもできます。低い整合性レベルで実行されているプロセスは、プロセスのアカウントが ACL を介してアクセスを許可されている場合でも、レジストリ キー/値を書き込んだり、変更したり、削除したりすることはできません。たとえば、保護モードで実行されている Internet Explorer は、現在ログオンしているユーザーの中程度および低整合性のレジストリ キー/値を読み取ることができますが、低整合性のキーのみを変更できます。[ 45 ]
セキュリティ以外の理由でレジストリ キーを削除または編集することはできません。NUL 文字を含むレジストリ キーは、標準のレジストリ エディターでは削除できず、RegDelNullなどの特別なユーティリティを使用して削除する必要があります。[ 46 ] [ 47 ]
Windowsの様々なエディションでは、長年にわたりレジストリのバックアップと復元に関して様々な方法がサポートされてきましたが、その一部は現在では非推奨となっています。
Windows 2000 以降のバージョンの Windows では、グループ ポリシー処理エンジンのレジストリ固有のクライアント拡張機能を介してレジストリ設定を強制するためにグループ ポリシーを使用します。 [ 53 ]ポリシーは、 gpedit.mscを使用して単一のコンピューターにローカルに適用することも、 gpmc.mscを使用してドメイン内の複数のユーザーとコンピューターに適用することもできます。
Windows 95、Windows 98、Windows ME、および Windows NT 4.0 では、管理者はポリシー ファイル ( POLICY.POL ) と呼ばれる特別なファイルをレジストリにマージすることができます。ポリシー ファイルを使用すると、管理者以外のユーザーがInternet Explorerのセキュリティ レベルやデスクトップの背景壁紙などのレジストリ設定を変更できないようにすることができます。ポリシー ファイルは主に、多数のコンピュータを所有し、不正なユーザーや不注意なユーザーから企業を保護する必要がある企業で使用されます。
ポリシーファイルのデフォルトの拡張子は.POLです。ポリシーファイルは、ユーザーごと、グループごと（「グループ」とは定義されたユーザーの集合）に、適用する設定をフィルタリングします。そのため、ポリシーファイルはレジストリにマージされ、ユーザーが設定を元に戻すことでポリシーを回避することを防ぎます。ポリシーファイルは通常、LAN を介して配布されますが、ローカルコンピュータに配置することもできます。
ポリシー ファイルは、Windows 95/Windows 98 ではpoledit.exeというファイル名の Microsoft の無料ツール、Windows NT ではコンピュータ管理モジュールによって作成されます。このエディタは、アクセス許可を使用するシステムで実行するために管理者権限が必要です。また、ローカル コンピュータの現在のレジストリ設定を直接変更することもできます。さらに、リモート レジストリ サービスが別のコンピュータにインストールされ、起動されている場合は、そのコンピュータのレジストリも変更できます。ポリシー エディタは、Windows シェルが提供する設定を含む.ADMファイルから変更可能な設定を読み込みます。この.ADMファイルはプレーン テキストであり、すべての文字列を 1 か所に保存できるため、ローカライズが容易です。
Windows NT カーネルは、「InifileMapping」と呼ばれる機能を使用して、INI ファイル関連のAPIをHKEY_CURRENT_USERなどのレジストリの仮想ファイルにリダイレクトすることをサポートしています。 [ 54 ] この機能は、16 ビット版Windows 用に作成されたレガシー アプリケーションが、システム フォルダーがユーザー固有のデータや構成の適切な場所とはみなされなくなった Windows NT プラットフォームで実行できるようにするために導入されました。この機能は元々 16 ビット アプリケーション向けに意図されていましたが、準拠していない 32 ビット アプリケーションもこの方法でリダイレクトできます。
Windows Vistaでは、限定的なレジストリ仮想化が導入されました。これにより、最小権限の原則を尊重せず、読み取り専用のシステム場所（HKEY_LOCAL_MACHINEハイブなど）にユーザーデータを書き込もうとする不適切なアプリケーションは、アプリケーション自体を変更することなく、より適切な場所に自動的にリダイレクトされます。
同様に、アプリケーション仮想化は、アプリケーションの無効なレジストリ操作をすべてファイルなどの場所にリダイレクトします。ファイル仮想化と併用することで、アプリケーションをマシンにインストールせずに実行できるようになります。
信頼性の低いプロセスもレジストリ仮想化を利用する場合があります。例えば、Windows Vista以降の「保護モード」で実行されているInternet Explorer 7または8は、ActiveXコントロールによるレジストリへの書き込みを自動的にサンドボックス化された場所にリダイレクトし、一部の種類のセキュリティ攻撃を阻止します。
アプリケーション互換性ツールキット[ 55 ]は、 HKEY_LOCAL_MACHINEまたはHKEY_CLASSES_ROOTレジストリ操作をHKEY_CURRENT_USERに透過的にリダイレクトできるシムを提供し、権限が不十分なユーザーに対してアプリケーションが動作しない原因となる「LUA」バグに対処します。
批評家たちは、Windows 95 のレジストリを単一障害点と呼びました。レジストリが破損するとオペレーティングシステムの再インストールが必要だったからです。しかし、Windows NT はトランザクション ログを使用して、更新中の破損を防いでいます。現在のバージョンの Windows は、データベースの更新中に停電や同様の壊滅的なイベントが発生した場合でも整合性を確保するために、2 レベルのログ ファイルを使用しています。[ 56 ]回復不可能なエラーが発生した場合でも、Windows はシステム起動中に破損したレジストリ エントリを修復または再初期化できます。[ 56 ]
libguestfsとhivex（ホストのWindowsインストール以外のシステム、非Windowsシステムを含む、レジストリの読み書きを行うツール）の作者であるRichard WM Jonesは、次のような批判をしています。 [ 27 ]
Windowsでは、プログラムデータの保存にレジストリを使用するかどうかは開発者の裁量に委ねられています。Microsoftは、データをXMLファイル（MSXML経由）またはデータベースファイル（SQL Server Compact経由）に保存するためのプログラミングインターフェイスを提供しており、開発者はこれらを代わりに利用できます。また、開発者はMicrosoft以外の代替手段を使用したり、独自のデータストアを開発したりすることも可能です。
Windowsレジストリのバイナリベースのデータベースモデルとは対照的に、他のオペレーティングシステムの中には、デーモンとアプリケーションの設定に別々のプレーンテキストファイルを使用するものの、管理の容易さのためにこれらの設定をまとめて管理するものもあります。
レジストリを使用することで克服できる、.INI ファイルの使用によって発生するその他の問題または制限を示しています。
{{cite book}}: CS1 maint: 複数の名前: 著者リスト (リンク){{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)