 <p>I thought so (the <strong>32 bit</strong> part). You're running into a problem generated by <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx" rel="nofollow">Registry redirection</a>.</p> <p>In other words (on 64bit <em>Windows</em>), for some registry keys (this one included) there are 2 separate locations: one for 64bit(default and old one) and other for 32bit(a new location). By default a 64bit app automatically uses the 64bit registry location; same thing for 32 bit (of course that can be programmatically modified - at least for 64bit apps). </p> <p>So, in order for 32bit apps that have some registry keys hardcoded to still work on 64bit <em>Windows</em> (remember the key hardcoded in the 32bit app is now 64 bit, and it's <em>invisible</em> to the app, while the <em>real</em> 32bit is someplace else), <em>Microsoft</em> came up with this approach. Same approach applies to paths on the filesystem (<em><strong>System32</strong></em> vs <em><strong>SysWOW64</strong></em> under <em>C:\Windows</em>).</p> <p>Now why does it work from cmdline? Being a 64bit OS, the default <em>cmd</em> is 64 bit (which launches the 64bit <em>reg.exe</em>), so it finds the key. Yes you have 2 <em>cmd</em>s (one under each of the above folders), actually (almost) all the <em>Windows</em> executables and dlls are <em>duplicated</em>.</p> <p>To test, start <em>cmd.exe</em> from <em>C:\Windows\SysWOW64</em>, and run the <em>reg</em> command and it will fail.</p> <p>Finally, to get past this, associate <em>.py</em> files (I noticed that you ran it directly) with a 64bit <em>Python</em> version (you might have to download and install it).</p>