4

I have a problem with my Visual Studio 2005 C# project. I have been using it under Windows XP, since Monday. Then my laptop broke down and on my new one I have Windows 7 64 bit and I am still using VS 2005.

There is no problem with compilation of the source, but when I run the program it breaks on the line below

OdbcConnection cn;
cn = new OdbcConnection("dsn=My_dsn_name;");

I get the error:

EnrtyPointNotFoundExcepition was unhalted

Unable to find an entry point named 'InterlockedIncrement' in DLL 'kernel32.dll'

I am trying to connect with a Postgres 8.4 database using PostgresODBC 64 bit driver.

Any solution or workaround is welcome. I need to stress that the solution I am building needs to run under Windows XP 32bit.

Updated information about the issue (from my respones to the comments but not only):

  1. When I tried to add new connection to my VS project I got the message ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application. I use Windows 7 64 bit, Postgres ODBC 64 bit Driver ver. 9.00.0200, Postgres 8.4 32 bit.
  2. I have never used Dependency Walker before. But I have opened kernel32.dll from both \system32 and \SysWOW64 and InterlockedIncrement is present in files from both folders.
  3. I have some TableAdapters, and I use them to fetch data from the Postgres. It was set when I was using WinXP, and it still works. On the other hand, when in VS2005 in the properties of TableAdapter I click on "..." next to Data->CommandText it displays a message Failed to call the ODBC driver connection utility.

EDIT: I added points 1-3 above.

MPękalski
  • 6,873
  • 4
  • 26
  • 36
  • That makes absolutely no sense. Could you check with Dependency Viewer that the supposedly missing export is present in kernel32.dll (both in C:\Windows\system32 and C:\Windows\SysWOW64). – David Heffernan Mar 17 '11 at 13:01
  • I have never used *Dependency Walker* before. But I have opened **kernel32.dll** from both *\system32* and *\SysWOW64* and **InterlockedIncrement** is present in files from both folders. – MPękalski Mar 17 '11 at 13:11
  • 1
    You're using the 32-bit version of depends.exe - the 32-bit version always loads the c:\system\syswow64 version of kernel32.dll, even if you try to load the 64-bit one. Try the 64-bit version of depends.exe and you will see that these exports are missing from the 64-bit version of kernel32.dll – Stewart Mar 17 '11 at 13:48

4 Answers4

5

On 64 bit windows these are not real functions exported from kernel32.dll - they are compiler intrinsics instead. The code that is P/Invoking that function should be using the Interlocked managed class instead.

They are intrinsics on 32-bit windows too nowadays, but the exported functions are still available from kernel32.dll on 32-bit windows for app compat reasons. Not a problem for 64 bit because there were no apps to be compatible with.

Stewart
  • 3,978
  • 17
  • 20
  • Well, in my 64 bit Windows, kernel32 has these exports. Indeed MSDN clearly documents it as so. So I don't believe this. – David Heffernan Mar 17 '11 at 13:13
  • 2
    Mine doesn't. Remember there are two versions of kernel32.dll on a 64-bit Windows system - the 32-bit one, which lives in c:\windows\SysWOW64, which has InterlockedIncrement, and the 64-bit one in c:\windows\system32 which doesn't. You're probably using the 32-bit version of depends.exe, which for some reason (probably file redirection - and if it is file redirection this is probably a bug in depends.exe) loads the 32-bit version of the DLL even if you load it from c:\windows\system32 – Stewart Mar 17 '11 at 13:47
  • Mine, Dependency Walker for Win32 ver 2.1.3790 run under Win7 64bit, shows that kernel32.dll in both folders has InterlockedIncrement. It does not load 32 bit version as it shows the path to the investigated file, and it differs in both cases. – MPękalski Mar 17 '11 at 13:51
  • 1
    @Stewart Yes you are right! File dialogs in 32 bit programs cannot reach 64 bit system folder other than through sysnative. I knew that but forgot it! Load it through sysnative and these exports are indeed missing. – David Heffernan Mar 17 '11 at 13:53
  • I have downloaded 64bit version and you are right! I would have never expected it, but it is true. Anyway, the 64bit version is available for download from http://www.dependencywalker.com/ – MPękalski Mar 17 '11 at 13:54
  • Removing the functions from kernel32.dll makes sense - the windows code doesn't use them because the microsoft compiler implements this as an intrinsic, and really all compilers should because calling the functions is expensive compared with the operation itself. 32-bit windows had to worry about compatibility with Windows 95 and apps written to work on a 386 where these operations could not be compiler intrinsics as the were more complex than that. – Stewart Mar 17 '11 at 14:00
5

I have just had exactly the same issue, and found a surprisingly simple solution: Use System.Data.Odbc instead of Microsoft.Data.Odbc in the imports.

Hagunenon
  • 51
  • 1
  • 1
1

My guess is there's something wrong with your driver. I can't be sure, but you might want to consider using something else. Npgsql looks pretty decent, and it's 100% C# code, so it should work on Windows XP 32-bit without any issues.

Scott Arrington
  • 12,325
  • 3
  • 42
  • 54
  • I do not know if it is a driver issue. However, I have some **TableAdapters**, and I use them to fetch data from the **Postgres**. It was set when I was using WinXP, and it still works. On the other hand, when in *VS2005* in the properties of **TableAdapter** I click on **...** next to *Data->CommandText* it displays a message **Failed to call the ODBC driver connection utility**. – MPękalski Mar 17 '11 at 13:30
1

I think I have solved problem, although I am not sure. However, I installed the 32bit version of Postgres ODBC driver and I used 32bit version of ODBC administrator C:\Windows\SysWOW64\odbcad32.exe to configure the connection. I found the information about the 32bit ODBC Administrator in the thread 64-bit-odbc-exception where one of the users refers to MSDN: Managing Data Sources.

I thought that I needed the same version of ODBC driver (regarting to number of bits) as my OS. I have also tried 64bit version of Postgres and ODBC driver, but it also did not want to work for me. The only solution was 32bit version of Postgres, and ODBC, and connection set in 32bit ODBC Administrator.

Regarding my VS project, I have Project->Properties->Build->Platform target set to x86.

Hope it helps somebody in the future.

Community
  • 1
  • 1
MPękalski
  • 6,873
  • 4
  • 26
  • 36