Solved

reg.OpenSubKey returns incorrect subkey counts and values compared to registry values

Posted on 2014-01-10
5
52 Views
Last Modified: 2016-06-13
I'm trying to programmatically return the ODBC driver list from the registry.  The values and names returned are very different (in total number, values, and language) than the list of values seen using regedit.  How do I get the values returned I am expecting?  NOTE: This is in Windows 8.1 64 bit.

This is the code used:
-----------------------
internal static List<String> GetSystemDriverList()
        {
            var names = new List<string>();
            Microsoft.Win32.RegistryKey reg = (Microsoft.Win32.Registry.LocalMachine).OpenSubKey("Software");

            if (reg != null)
            {
                reg = reg.OpenSubKey("ODBC");
                if (reg != null)
                {
                    reg = reg.OpenSubKey("ODBCINST.INI");
                    if (reg != null)
                    {

                        reg = reg.OpenSubKey("ODBC Drivers");
                        if (reg != null)
                        {
                            // Get all DSN entries defined in DSN_LOC_IN_REGISTRY.
                            foreach (string sName in reg.GetValueNames())
                            {
                                names.Add(sName);
                            }
                        }
                        try
                        {
                            reg.Close();
                        }
                        catch { }
                    }
                }
            }

            return names;
        }


---------
These are the actual registry values:
Registry
But, this is what is returned (first 14 entries shown in the image -- very different than the actual registry values):
returned ODBC driver values (erroneous)
0
Comment
Question by:temerious
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
5 Comments
 
LVL 21

Accepted Solution

by:
Craig Wagner earned 250 total points
ID: 39772437
On the Build page of your project's properties it is probably set to either Any CPU or x86. Change it to x64 and you should get the results you expect.
0
 
LVL 40

Assisted Solution

by:Jacques Bourgeois (James Burger)
Jacques Bourgeois (James Burger) earned 250 total points
ID: 39773459
My understanding is that the registry on 64 bits computers is in 2 parts, and the section that is used maps to the Platform target as hinted by Craig.

If you compile to x64, you end up in the standard HKEY_LOCAL_MACHINE\SOFTWARE\ node of the registry, which is the default for a 64-bit application. Theses are the 64-bit drivers are located, and this is what you see in your screen shot.

If you compile to x86, then you end up in the other section of the registry that has been set (as I understand) to enable 32-bit application to keep working properly on 64-bit computers. The results you get then comes from HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC, where the 32-bit ODBC drivers are located. This is what you get in your code.

 (Wonder what the Wow is for. Might be that the programmer who decided on that name is an avid player of World of Warcraft :-)

If you compile with AnyCPU, then where you end up depends on whether the system will end up working in 32-bits ou 64-bits when the application is launched, with some interference from the Prefer 32-bit build option. As I understand it, it depends on the dlls used by the application. This is usually the best way to compile.

The reason why it works so is that 64-bit applications can have problems using 32-bit dlls, since they use values that might be too big for 32-bit.
0
 
LVL 21

Expert Comment

by:Craig Wagner
ID: 39773768
FWIW, WoW64 stands for Windows on Windows 64-bit (or Windows on 64-bit Windows).
0
 
LVL 40
ID: 39773784
Thanks Craig. But want an awful expression.

I was thinking that now that the compiler is a lot slower (compared to previous versions of Visual Studio), maybe someone as Microsoft was playing WoW while he waited for Windows 8 64-bit to compile :-)
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Many of us here at EE write code. Many of us write exceptional code; just as many of us write exception-prone code. As we all should know, exceptions are a mechanism for handling errors which are typically out of our control. From database errors, t…
More often than not, we developers are confronted with a need: a need to make some kind of magic happen via code. Whether it is for a client, for the boss, or for our own personal projects, the need must be satisfied. Most of the time, the Framework…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

742 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question