3

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?

Community
  • 1
  • 1
Rumi
  • 1,290
  • 1
  • 11
  • 17

3 Answers3

2

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.

Lieven Keersmaekers
  • 57,207
  • 13
  • 112
  • 146
Mason Wheeler
  • 82,511
  • 50
  • 270
  • 477
  • Mason, if these two points were the problem this same source code compiled in the customer's or supplier's machines would also crash, wouldn't it? The problem is -ironically- that it works. The source code I list here produces a crashing executable only when I compile it. – Rumi Nov 29 '10 at 09:39
  • @Rumi: That depends. If things are close enough, it can accidentally work under some circumstances and crash in others. That's been known to happen. Just double-check it to be certain. – Mason Wheeler Nov 29 '10 at 14:34
2

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
Rumi
  • 1,290
  • 1
  • 11
  • 17
  • 1
    Rumi, thanks for posting the resolution. But I would think you would accept [Mason's answer](http://stackoverflow.com/questions/4298380/calling-delphi-dll-crashes-vb6-exe-with-run-time-error-2147418113-8000ffff/4298974#4298974) as the correct one since it is the correct answer. – Sertac Akyuz Dec 01 '10 at 22:25
  • You're right. I did that. Perhaps you should click the up arrow on my resolution so that people can see it. – Rumi Dec 02 '10 at 06:58
1

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

Chris Thornton
  • 15,620
  • 5
  • 37
  • 62
  • Chris, I have checked it with procexp. The test exe compiled on customer pc (cust.exe) and the one compiled on my pc (my.exe) load and use the same dll. Yet cust.exe works, my.exe crashes. – Rumi Nov 29 '10 at 09:32