![]() ![]() To what degree that key is reliably random on different machines isn't that clear to me, let's just say that this value is a pretty attractive target for the kind of users that are not very interested in paying the license fee for your product either. Just keep in mind that you are not reading the same information when you use Win32_OperatingSystem.SerialNumber. ![]() Which allows you to pass RegistryView.Registry64, ensuring that you'll read the non-redirected keys. If you are really stuck with x86 mode, typically because you have a dependency on 32-bit native code that you can't update then the next workaround is to use the. Your program itself however works "better" if you have the setting at An圜PU, including not getting bitten by the file system and registry redirection appcompat features built into Windows. And the Edit + Continue feature only works for 32-bit code. ![]() Which has a few limitations like not supported mixed-mode debugging. Particularly when debugging, VS is a 32-bit process itself so requires the remote debugger if your program executes in 64-bit mode. Microsoft prefers x86, Visual Studio works better with 32-bit mode processes. The x86 selection is the default for VS2010 and up, previously An圜PU was the default. Your program is actually reading the value of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\MachineGuid. Which has a number of side effects, the one that matters here is that access to registry keys are redirected. This setting forces your program to run in 32-bit mode on a 64-bit version of Windows. On VS2012, the "Prefer 32-bit" checkbox matters. Project + Properties, Build tab, Platform target combobox. This problem is caused by the platform target selection for your EXE project. Which is probably why it doesn't work reliably among different versions of Windows ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |