Re: problem connecting to db.

From: Charles Hooper <hooperc2000_at_yahoo.com>
Date: Mon, 7 Jan 2008 06:37:56 -0800 (PST)
Message-ID: <9c983fd3-c809-46dd-a5e0-f605b6ae8939@k39g2000hsf.googlegroups.com>


On Jan 7, 8:00 am, "Mr. X." <nospam_at_no_spam_please.com> wrote:
> All of the dlls (before running) are :
> MSVBVM60 - timestamp : 23/2/04 8:42a and link timestamp 24/2/04 6:15p
>
> All others have the same timestamp :
> oleaut32, ole32, user32, rpcrt4, ntdll, kernel32, gdi32, advapi32 :
> timestamp : 19/6/03 12:05p and link timestamp 20/6/03 4:43a.
>
> versions are :
> msvbvm60 - 6.0.97.82
> oleaut32 - 2.40.4522.0
> ole32 - 5.0.2195.6692
> user32 - 5.0.2195.6688
> rpcrt4 - 5.0.2195.6701
> ntdll - 5.0.2195.6685
> kernel32 - 5.0.2195.6688
> gdi32 - 5.0.2195.6660
> advapi32 - 5.0.2195.6170
>
> How can I know that some of the version are wrong versions (Is it by
> dependency walker,
> or somewhere on some help/tutorial/technical reference arround the internet)
> ?
>
> Also, I see that I get the following errors in the details log (dependency
> walker).
>
> getProcAddress (NTDLL.DLL) "NtCompareTokens" called from "OLEDB32.dll",
> returned null ...
>
> LoadLibraryExW("C:\program files\common files\system\ole
> db\Resources\1033\MSDASQLR.dll") returned null ...
> ... indeed I have this folder only on my computer (development with VB 6.0
> installed,
> ... but not the file MSDASQLR.dll, neither on the server where the program
> is installed).
>
> GetProcAddress(kernel32.dll") IsTNT called from "VBAME.dll", returned null
> ...
> ProcAddress(kernel32.dll") IsTNT called from "MSVBVM60.dll" , returned null
> ...
> Address(kernel32.dll") IsTNT called from "OLEAUT32.dll", returned null ...
>
> Thanks :)

I previously stated in this thread:
"Windows uses dynamic link libraries (DLL) files that are read into memory as needed, and there are several needed by your VB program, as well as other programs that may be running at the same time. When Windows needs to read a DLL file, it first looks in the same folder as
the VB program, and then searches the system path (you can check the value of the current system path by opening a command prompt and typing PATH). Some DLL files need the help of other DLL files to work
correctly, and the helper DLL files must be the correct version. It can be very difficult to check all files needed by your VB6 program. A program that can help is Dependency Walker, which is installed automatically with newer versions of Visual Studio."

The Dependency Walker actually shows that Windows will first check the Windows registry for registered DLLs before looking for DLLs in the application path.

What you are trying to perform is capture a log of what DLLs (and their locations) are loaded when the application is working correctly, so that you can compare the log with one from when the program hangs during the connection request. As the loaded DLLs are shared among multiple programs running at the same time, it is possible for one program to load a version of a DLL that is incompatible with other programs that will be started later.

According to the Dependency Walker FAQ, some errors are to be expected:
http://www.dependencywalker.com/faq.html

I just tested another computer running Windows XP. It does not look for MSDASQLR.dll when connecting with OraOLEDB.Oracle, but does look for the file when connecting using an ODBC connection. I have not tested a Windows 2000 computer yet, but I suspect that it will not attempt to access MSDASQLR.dll when connecting using OraOLEDB.Oracle. You may want to check the names of the User DSN and System DNS entries in the ODBC control panel.

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. Received on Mon Jan 07 2008 - 08:37:56 CST

Original text of this message