Rumi
Rumi

Reputation: 1310

Calling Delphi DLL crashes VB6 exe with "Run-time error '-2147418113 (8000ffff)' Method '~' of object '~' failed", but only on some machines!

I have searched for hours but could not find anything similar.

The crash has two flavors; one is with "Run-time error '-2147418113 (8000ffff)' Method '~' of object '~' failed" and the second flavor is a total crash where Windows asks if I want to report this to Microsoft. In the second case I chose to debug once and it showed "Unhandled exception in App.exe (OLEAUT32.DLL): 0xC0000005: Access violation."

The Disassembly screen showed the yellow pointer at top line of:

>> 771148A4  mov ecx, dword ptr [esi]
   771148A6  add ecx, 15h
   771148A9  and ecx, 0FFFFFFF0h
   771148AC  push ecx
   771148AD  push esi
...

The problem occurs when calling a particular essential function in a third-party Delphi DLL, but I cannot declare outright that the DLL is buggy because this happens only in the program executables I compile. This same dll is used in hundreds of other customers and (at least for now) I am the only one running into this problem. The same source code compiled in the customer's PC, or the 3rd party supplier's office works fine.

So the problem boils down to this: VB6 with SP6 produces different binary exe files from the exact same source code. The one compiled on my pc works fine in my pc, and a clean virtual pc I installed to check this, but does not work anywhere it should; and the one compiled in the customer or the 3rd party supplier works fine everywhere except my pc.

It is unlike the problem Boost describes (see this link) since both the IDE and the compiled application behave in the same manner on all machines. They either work fine or break terribly.

Public mXApp As XObjects.XApplication

Public Sub Main    
    On Error Resume Next
    Set mXApp = New XObjects.XApplication
    If Err.Number = 0 Then
        MsgBox "Found: " & mXApp.Version & vbCrLf & mXApp.GetAppPath
    Else
        MsgBox "XApp DLL not found. " & Err.Number & ": " & Err.Description
    End If
    Err.Clear
End Sub

Public Sub Login(Byval uid As String,  Byval pwd As String, Byval companyNr as Long)
Dim ok as Boolean
    ok = mXApp.Login(uid, pwd, companyNr)' >> CRASH! Program never gets to the next line.'
    If ok Then
        MsgBox "Login success"
    Else
        MsgBox "Login fails"
    End If
End Sub

Note that after the mXApp object is created, two function calls are done -namely Version and GetAppPath- without any problem. The crash occurs in the Login call. VB IDE Object browser displays the definitions of the three functions as:

Function Version() As String
Function GetAppPath() As String
Function Login(UserName As String, Password As String, FirmNr As Long) As Boolean

Does anyone have any solutions or (equally usefully) ways that I can make the supplier reproduce this problem in their own machines?

Upvotes: 3

Views: 2341

Answers (3)

Rumi
Rumi

Reputation: 1310

Problem Solved! Mason was quite right when telling me to double-check:

...make sure the DLL function and the import header for it in the VB program are using the same calling convention. If VB is putting the paramters in one place and the Delphi DLL is looking for them somewhere else, you get undefined behavior.

The DLL on my pc and the one in the customer were slightly different builds all along. And I had assumed that they had exactly the same interface. But wait before thinking I was careless; I did not just assume this, I had compiled two different executables after registering both versions of the DLL long before posting my question here.

When I thought I had tried the second dll, I was mistaken. I had registered the dll version 1.1 on my pc. The Object Viewer showed the declarations in the question. I compiled the executable and tested. And then without exiting the IDE, I registered the dll version 1.2 and compiled again assuming that the VB compiler would read the dll interface during compilation. Well this assumption was wrong. It turns out that the IDE had to be restarted.

Problem was solved after the supplier of the dll told me there was an optional new parameter, but they did not mention it earlier assuming this would not be problem since it was optional.

Below is the difference that caused the crashes:

Function Login(UserName As String, Password As String, FirmNr As Long, [PeriodNr As Long]) As Boolean

Upvotes: 2

Mason Wheeler
Mason Wheeler

Reputation: 84650

Well, it's hard to say for sure without being able to see the Delphi side of it, but when you get problems like this in DLL calls, there are two standard things to check first.

First, make sure the DLL function and the import header for it in the VB program are using the same calling convention. If VB is putting the paramters in one place and the Delphi DLL is looking for them somewhere else, you get undefined behavior.

Second, make sure you're using the same string type on both sides. If this is COM, your string type should be the COM BSTR type, known as WideString in Delphi. Not sure what VB calls it. If you're passing the DLL a different string type than it's expecting to receive, it'll get corrupt data.

Double-check these two things and see if that doesn't fix it.

Upvotes: 2

Chris Thornton
Chris Thornton

Reputation: 15817

Make sure you're loading the right DLL. Process Explorer from SysInternals will show you the DLLs being used by any app (configure it to show DLLs in the lower pane). Maybe you're loading a different version of the DLL, unknowingly. You can run it directly here: http://live.sysinternals.com/ click on procexp.exe

Upvotes: 1

Related Questions