I saw this problem in my work. If you open a screen installation project and look at the components, some will have the COM Extract at Build property set to yes. Expand this component and see the files. Right-click on them to view the properties. If the files have a Self Register Check, this will cause the problem that you see. When we went and removed COM Extract at Build from all of our components, which had files that independently registered the problem, they left.
When you install your product on a 64-bit machine, it will insert the wow6432node key into the registry. On a 32-bit machine, it will simply add the wow6432node registry key to the registry, which should never exist on a 32-bit machine.
So, to clarify the problem, it depends on the specific components for which the Com Extract at Build property is set to yes, and one of the files contained in this component, set for self-registration. This results in a wow6432node error. The answer to your question about why you see wow6432node nested keys is a bit more complicated.
What I think is happening in your case, you create a redistributable that has a wow6432node problem. When your main installer sets out to create the necessary registry keys, it checks to see if the machine is 64-bit. If so, it puts everything under the wow6432node key. So far, everything works, but then it follows a redistributable that contains an error. He then installs everything on his own Wow6432node key, which is now contained in the main installer. You can try to verify this by installing the application on a 32-bit machine. Then you should see only 1 wow6432node key, not nested keys. This 1 wow6432node key is one that is created by mistake from the problem described above that is contained in your redistributable.
(edited for clarification)
source share