The K1000 5.3.x agent is a 32bit application. When it is installed on a 64bit Windows platform, things it attempts to do can get redirected by the OS. Simple things like trying to read or write to the registry or system32 folder doesn't always function the same as the agent's predecesssors. There are ways to account for/workaround when dealing with these redirects.

This MS KB article will show you similar to the information I’m placing below:
http://support.microsoft.com/kb/942589

On a Windows x64 machine

1) A 32-bit application maps as follows:

    - c:\windows\system32 -> c:\windows\syswow64 (32-bit)
    - c:\windows\syswow64 -> c:\windows\syswow64 (32-bit)
    - c:\windows\sysnative -> c:\windows\system32 (64-bit)

2) A 64-bit application maps as follows:

    - c:\windows\system32 -> c:\windows\system32 (64-bit)
    - c:\windows\syswow64 -> c:\windows\syswow64 (32-bit)
    - c:\windows\sysnative -> not valid

This will also affect registry keys. When needing to write to the actual 64bit registry, you need to call the reg command from sysnative. If you are using a batch that has parameters, the batch will switch back to 32bit redirects due to switches when executed by the agent.

On the registry, the 5.3.X agent has another way of accounting for the 64bit registry. If you aren’t doing the registry commands via a batch or trying to leverage regedit or reg.exe, you can use things like HKLM64 to reference the 64bit hive instead of allowing the agent to get redirected to the 32bit hive which populates the wow6432node locations in the 64bit registry. Leveraging the HKLM64 is very useful in Custom Inventory Rules too.