Hi, Heribert -

I believe I know why this happens and I have a solution. Please forgive the length of this reply, but I want fully explain the issue.

The Windows OS re-directs (or "reflects") registry operations when you are running a 32-bit app on a 64-bit version of Windows. If you run your app as a 64-bit app, it will find and return the machine GUID as expected, but when it's 32-bit, Windows looks elsewhere due to reflection. Here is a link to a post in StackOverflow.com that put me on the right track:

    https://stackoverflow.com/questions/53100174/error-2-reading-software-microsoft-cryptography-machineguid-on-win-8-8-1-and-7

The actual key where Windows reflects the request to is:

    HKEY_USERS\S-x-x-xx-xxxxxxxxxx-xxxxxxxxxxx-xxxxxxxxxxx-xxxx\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Microsoft\Cryptography

The actual registry key will be in each user's personal subkey (I've xxx'd mine out for obvious reasons).

The PB registry functions utilize the normal Windows API registry functions as you would expect, but there are non-standard settings/options that can be used to ask Windows to not reflect the query request. This is what the StackOverflow.com post explains. Using the code posted there as a guide, I've been able to call the same WinAPI functions from PB and obtain the machine GUID in a 32-bit app.

I've attached my single-window, sample app that contains the external function declarations for the WinAPI functions and the needed PB code to obtain the machine GUID. The app works in both 32-bit and 64-bit from PB 2017 and up.

I hope this helps you out.

Best regards, John