This week I found a problem with my Biztalk Solution deployed in an 64 bits server machine.
I have orchestrations with maps that have some Scripting Functoids witch use methods from a auxiliary dll. This dll have some methods that requirer access to a database. And I'm keeping the connectionstring in registry.
After the deploy of my orchestrations on 64 bits machine I ran a test and found that BTS couldn't access registry. So far so good, I forgot to give permission to the registry key where I saved connectionstring. After giving permissions I re-ran the test and got the same error!!!
I tried every thing to find the problem, even tried to find out what was happening with processmon (from sysinternals).
After some time, the problem was discovered. I was putting the registry key in HKLM\Software\MySoftware\ConnectionString and BTS was trying to get the registry key:
HKLM\Software\Wow6432Node\MySoftware\ConnectionString.
This happens because I'm dealing with a 64 bits machine and the SO internally "changes" the key I'm looking for ("Registry keys specific to 32-bit applications are stored in a branch under HKEY_LOCAL_MACHINE\Software\WOW6432Node.").
By the way the problem was found with regmon (processmon hides this errors about registry access).
This one was tricky to find because in my code I explicitly say I want to read HKLM\Software\MySoftware\ConnectionString registry key, and I made a test application that ran in the same machine with the same user that BTS and this test application was able to read the key (this happened because my test application was running in 64 bits and BTS is running in a 32 bit emulation environment - the Biztalk installed was the 32 bits version and should have been the 64 bits version).
A useful link to understand a little more about this 32/64 bits windows trouble.
