How do I debug a privileged-instruction fault from calling a DLL function?

Question

I have the following functions defined for a 3rd-party DLL, which we don't have control over:

const
  DLL = 'Qarapea.dll';

function QARapid_Open(IniFile: shortstring; Section: shortstring): integer; stdcall; external DLL;
procedure QARapid_EndSearch(); stdcall; external DLL;
function QARapid_Count: integer; stdcall; external DLL;
function QARapid_Search(vs: shortstring): integer; stdcall; external DLL;
function QARapid_FormatAddr(ItemNumber: integer; Buffer: PAnsiChar; BufferSize: integer):     integer; stdcall; external DLL;
procedure QARapid_Close; stdcall; external DLL;

I call the functions in the following way:

procedure TFormMain.ButtonStaticLookupClick(Sender: TObject);
var
  Res: integer;
  ACode: shortstring;
  IniFile, Section: shortstring;
begin
  try
    ACode := PrepareCode(EditCode.Text);
    IniFile := ExtractFilePath(ParamStr(0)) + 'DllIni.ini';
    Section := 'Default';
    QARapid_Open(IniFile, Section);
    try
      Res := QARapid_Search(ACode);
      Res := QARapid_Count;

    finally
      QARapid_Close;
    end;

  Except on E: Exception do
    MessageDlg(E.Message, mtError, [mbOK], 0);
  end;
end;

Everything seems to be OK until I call the QARapid_Count function, when I get the following error:

QAS.exe faulted with message: Privileged instruction at 0x0012eff4. Process stopped. Use step or run to continue.

I'm don't know where to start looking for the fault because the CPU debug window is opened.

How can trace what is going wrong?

Is calling convention for 'QARapid_Open' different? or is it a copy&paste error? — Sertac Akyuz, Sep 06 '12 at 08:50
are you sure you correctly translated the API ? With DLL you have no warranty that your header is not outdated or correct by some other means. Assuming your DLL itself written with C++Builder or Delphi, it might have different version of FastMM4, and when EXE and DLL try to merge their Heap pools - corrupting the structures of each other. Just speculating though. Hopefully it should not be the case. — Arioch 'The, Sep 06 '12 at 09:02
what should return QARapid_Open ? what does it return actually ? what does it mean ? — Arioch 'The, Sep 06 '12 at 09:05
I mean it's missing the stdcall directive. Is it intentional? — Sertac Akyuz, Sep 06 '12 at 09:10
That address looks like it's on the stack. Is it? If so, do you have DEP enabled in your process? Why would the DLL be executing code on the stack? — David Heffernan, Sep 06 '12 at 09:10
Also, what kind of lousy DLL uses shortstring? A DLL that can only reasonably be called from Delphi! — David Heffernan, Sep 06 '12 at 09:11
And there's more. Your try/finally block is all messed up. You can call `QARapid_Close` without calling `QARapid_Open`. Put the `try` immediately after the call to `QARapid_Open`. And why aren't you checking the return value of `QARapid_Open` for errors? — David Heffernan, Sep 06 '12 at 09:18
According to comments in the question here, http://stackoverflow.com/questions/6474278/what-specifically-causes-eprivilege-to-be-raised DEP is not the issue. Perhaps your DLL has not heard of NT. I presume you contacted the vendor of the DLL to ask them for support. What did they say? — David Heffernan, Sep 06 '12 at 09:20
I cannot believe I missed the 'stdcall' for the QARapid_Open!! I hang my head in shame! I now get a access violation error instead, but looking at the return code for QARapid_search, it is -9804. I'll have to try and find some documentation/contact the vendor for help. — Pieter van Wyk, Sep 06 '12 at 09:40
@PietervanWyk What makes you think that the DLL uses shortstring? — David Heffernan, Sep 06 '12 at 09:45
@Pieter you'd better start with checking QARapid_Open And additionally run SysInternals Process Monitor to check if you program realyl opens ini file or something else. — Arioch 'The, Sep 06 '12 at 10:06
@DavidHeffernan We've previously had some issues with DLL's compiled in D2007 which returned unreadable values using string as parameters but worked ok when we used shortstring. — Pieter van Wyk, Sep 06 '12 at 10:41
@PietervanWyk So you are just guessing as to how to call this DLL? It's exceptionally unlikely that `shortstring` is appropriate. — David Heffernan, Sep 06 '12 at 10:44
@DavidHeffernan I know the function names are correct as we have an old D2007 app that uses the dll successfully. We are rewriting the app in Delphi XE and have run into trouble. — Pieter van Wyk, Sep 06 '12 at 11:41
@PietervanWyk Can you post the exact declaration as it exists in D2007 then? Presumably it is a unicode issue. Char/PChar used to be Ansi chars, but are Wide chars in XE. If your dll hasn't changed, you should change (amongst others) PChar to PAnsiChar. — GolezTrol, Sep 06 '12 at 13:28
@GolezTrol I have replaced all the string variables with ansistring and the pchar with pansichar. Everything now works ok. Thank you for all your help. — Pieter van Wyk, Sep 06 '12 at 15:16

score 0 · Accepted Answer · answered Sep 06 '12 at 13:48

0

Read the QuickAddress Rapid API guide, then fix your Delphi imports accordingly.

answered Sep 06 '12 at 13:48

Jeroen Wiert Pluimers

23,965
9
74
154

Thank you for the document. I have replaced all the string variables with AnsiString and the PChar with PAnsiChar (See comment by GolezTrol). The function calls now work ok. – Pieter van Wyk Sep 06 '12 at 15:18
1

XE2 porting ain't that difficult (: Getting the right docs or/and header files is the most important step (Right now I'm working on a Delphi interface to the WebSphere MQ DLLs, it is a lot of work, but the difficulty level is OK, and the number of errors IBM made in their C header files is also OK). – Jeroen Wiert Pluimers Sep 06 '12 at 21:45

How do I debug a privileged-instruction fault from calling a DLL function?

1 Answers1