これがおそらく、異なるバージョンの Windows 間で確実に動作しない理由です。
いいえ、それは理由ではありません。この問題は、EXE プロジェクトのプラットフォーム ターゲットの選択が原因で発生します。プロジェクト + プロパティ、ビルド タブ、プラットフォーム ターゲット コンボボックス。AnyCPU ではなく x86 に設定しています。VS2012 では、「32 ビットを優先」チェックボックスが重要です。この設定により、プログラムは 64 ビット バージョンの Windows で 32 ビット モードで実行されます。これには多くの副作用があります。ここで重要なのは、レジストリ キーへのアクセスがリダイレクトされることです。プログラムは実際に HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\MachineGuid の値を読み取っています。これは存在しません。
x86 の選択は VS2010 以降のデフォルトであり、以前は AnyCPU がデフォルトでした。Microsoft は x86 を好み、Visual Studio は 32 ビット モードのプロセスでより適切に動作します。特にデバッグ時には、VS 自体が 32 ビット プロセスであるため、プログラムを 64 ビット モードで実行する場合はリモート デバッガが必要です。混合モードのデバッグがサポートされていないなど、いくつかの制限があります。また、エディット コンティニュ機能は 32 ビット コードでのみ機能します。ただし、Windows に組み込まれているファイル システムやレジストリ リダイレクト appcompat 機能に影響されないなど、AnyCPU に設定すると、プログラム自体は「より良く」動作します。
通常、更新できない 32 ビット ネイティブ コードに依存しているために x86 モードで本当に行き詰まっている場合、次の回避策は .NET 4+ RegistryKey.OpenBaseKey() メソッドを使用することです。これにより、RegistryView.Registry64 を渡すことができ、リダイレクトされていないキーを確実に読み取ることができます。
確かに、WMI を使用することは回避策です。Win32_OperatingSystem.SerialNumber を使用する場合、同じ情報を読み取っていないことに注意してください。そのキーが異なるマシンでどの程度確実にランダムであるかは、私には明確ではありません。この値は、製品のライセンス料を支払うことにあまり関心がない種類のユーザーにとって非常に魅力的なターゲットであるとだけ言っておきましょう。
最後になりましたが、Windows にまったく依存しない独自の一意の ID を生成するのは非常に簡単であることを考慮してください。顧客が自分のマシンで Windows を更新するときに顧客を怒らせないというかなりの利点があります。Guid.NewGuid() を 1 回使用して、値をファイルに保存するだけです。ドライブが故障すると失われますが、通常は製品も失われます。