none
Cause Of Error '48' (Error in loading DLL) When Running VB6 Application?

    Question

  • I get the Error '48' when running on Computer #1, but Do Not get the error when running on Computer #2.  Both computers are running Windows 7 SP1.  Here is a summary of my problem:

    1) Trying to run a rather complex VB6 Application (compiled)

    2) The identical application software runs without problems on MANY (> 100) other W7 Computers, including my Computer #2.

    3) The App fails on Computer #1 (when starting) with the following error message:

    Run-Time Error '48'

    Error in loading DLL

    I have identified the first line of code where the error occurs to the line that is underlined and begins "For Each tdTables" in the code snippet below:

    Public Sub ReLinkTables()

    Dim tdTables As TableDef, strTemp As String, dbCountyHunter As Database, tdNew As TableDef, I As Integer, lngAttribute As Long


    Dim strXX As String


    Dim strMsg As String ' For Test Message Box String

    ' Following Will Be Common To ALL Standard Error Handling Routines
    Dim blnErrorFixAttempted As Boolean, blnReportToTeam As Boolean
    Const strModuleName = "ReLinkTables" ' Module Name Will Change For Each Module!


    ' Initialize Local Variables For This Routine
    Const lngLinked = 1073741824
    blnReLinkProblem = False

    On Error GoTo ErrorHandler

    Set dbCountyHunter = OpenDatabase(strDataFolder & "\" & KLstrFilePrefix & strCallMine & KLstrFileSuffix, False, False, ";pwd=" & KLstrDBPassword & "")

    I = 0

    For Each tdTables In dbCountyHunter.TableDefs
    I = I + 1
    strTemp = tdTables.Name
    lngAttribute = tdTables.Attributes

    If lngAttribute = lngLinked Then
    dbCountyHunter.TableDefs("" & strTemp & "").Connect = ";DATABASE=" & strDataFolder & "\County Hunters - Common.mdb;pwd=" & KLstrDBPassword & ""


    dbCountyHunter.TableDefs("" & strTemp & "").RefreshLink
    End If

    Next

    blnRelinkDone = True

    End Sub

    The purpose of this Subroutine is to re-link tables in 2 Access mdb files (if they should happen to not be linked properly).

    In an attempt to narrow down which dll file might be causing the problem, I searched ALL dll and ocx files in the SysWOW64 folder for the string "TableDefs" and only found one file. This was file "MSRDO20.DLL" which is one of the dependent files for "MSRDO20.OCX" in the same folder. Both of these files are present on the problem machine in the correct folder (SysWOW64). I believe both files are registered, but am not totally certain.

    Inspired by the Microsoft article at http://support.microsoft.com/kb/833220 (that didn't fix Computer #1!) I found that I can reproduce the identical problem on Computer #2 by simply un-registering the file "dao360.dll" (in the C:\Program Files (x86)\Common Files\microsoft shared\DAO folder).  However, going back and immediately re-registering the same file doesn't cure the problem!  I have to load a restore point to regain normal operation on Computer #2

    I have also tried to cure the problem by re-installing the VB application with the UAC at its lowest level and anti-virus programs inactive.  All unsuccessful!

    Also, a "Repair Install" of Windows 7 is not an option for Computer #1 since it is an OEM installation of Windows.

    I believe I have wandered into a "DLL Hell" situation here!

    Please answer the following questions if you can:

    1) Do you think I may have located the file (MSRDO20.DLL) which can't load or is it dao360.dll?

    2) If either is the culprit, what do you recommend I do to fix the problem?

    3) If No, can you give me a better method to determine what the culprit dll file is or a better way to just solve the problem?

    4) Is there a utility program which will check that all Windows 7 SP1 WDAC system files are properly installed (especially those needed to support Visual Basic 6) and are the correct version, in the correct folder, and are correctly registered?

    (Incidentally, I have tried SFC and it shows NO errors and doesn't fix the problem)

    5) If no such utility exists, can you point me to a resource (File Manifest?) that lists ALL system files (just those needed to support VB 6 operation) normally installed by Windows 7 along with correct Version/date and the correct folder in which they should be found?

    Many Thanks For Any Help!

    Matt

    • Moved by Bob_BaoMVP Monday, March 26, 2012 9:59 AM (From:Visual Basic General)
    Thursday, March 22, 2012 11:34 PM

All replies

  • If you unregistered that particular dll, ran the program, and reregistered the dll - and it didn't work, you may have a specific registry key that is not being supplied with the standard registraton options.  I would check the registry entries of the restored and working dll against the registry entries for the pc that isn't working using regedit.  If they are not the same, then perhaps there is an option in the registration function that will provide identical settings.

    That would be my first guess, that some program or other has been installed on the computer that isn't working that included the offending dll, and this program registered it without some specific switch/option.  Like installing VStudio Express after having installed VStudio pro or VB6, the Express version will effectively restrict all the installed Studio dlls to it's limitations... ie - data objects don't work.

    Dan Kirk

    In short, you might be dealing with a dll that doesn't have the 'shared' attribute even though it's in the 'shared' folder.

    • Edited by Dan_Kirk Friday, March 23, 2012 1:25 AM
    Friday, March 23, 2012 1:11 AM
  • Greetings Matt,

    I have encountered many related issues when users of my legacy VB6 applications have upgraded to Windows7.

    Many of the DLL and OCx files used by the VB6 applications have been replaced over the years by newer technologies. As a result they may not be included in Windows 7.  Other applications may install these applications. 

    If you installed the VB6 applicaiton before installing the ODBC driver (connector) for mySQL, the VB6 application will usually fail to properly reference the required resources. 

    Here is a link to a help file that might help.  http://support.microsoft.com/kb/195474/c  It gives you a procedure to identify all of the support files (and their versions) for an application.

    If you have access to VB6, you can also try loading your project and then looking for the "References" menu item. The check marks indicate all of the DLL and OCX files that are being reference by the project. If you see the word "Missing" in the list you will need to locate the correct library manually.

    If this does not solve your problem, please list the checked libraries(including version information) so that we can provide further help.

    Thanks,

    Mike Corkery, MCT, MCITP, MCPD, MCSD, MCAD, MSF, MCDBA, etc.

    Friday, March 23, 2012 2:57 AM
  • Be aware that only the runtime of VB6 on not updated W7 computers is supported.

    Also that this forum is not for vintage VB6 versions. Look for that in this link

    http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/6a0719fe-14af-47f7-9f51-a8ea2b9c8d6b


    Success
    Cor

    Friday, March 23, 2012 5:31 AM
  • Hi Matt,

    Did you ever figure out which DLL was the problem?  I am seeing this error pop up more frequently on newer Win7 PCs.

    Thanks.

    Friday, November 16, 2012 5:49 PM
  • The Green Man,

    I also recently encountered the same problem. I fixed it by looking at my program's processes using  process monitor and finding the last few processes before it threw the "Error in loading DLL" message. I discovered that my program was looking for the DLL on the desktop.

    Here are the steps that fixed the problem for me:

    1. Unregister any DLL from the wrong location(s) using regsvr32 -u for example regsvr32 -u "C:\data.dll"
    2. Register the DLL to the locations were your program is referencing the DLL (ex: regsvr32 "C:\Correct location\data.dll")

    Hope this helps.

    L.O.R




    • Edited by lrami03 Thursday, November 29, 2012 8:26 PM typo
    • Proposed as answer by lrami03 Thursday, November 29, 2012 8:27 PM
    • Unproposed as answer by lrami03 Monday, December 10, 2012 4:27 PM
    Thursday, November 29, 2012 8:25 PM