dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 12 of 12

Thread: Odd error.

  1. #1
    Join Date
    Oct 2011
    Posts
    14

    Odd error.

    edit: The error show up after reaching the last }
    and it shows up even if I only keep the bcStartPCI(0) inside the function.

    In a command application (MFC) I wrote:

    bool AClass::SearchGPS(void)
    {

    int errorcode = bcStartPCI(0)
    if(errorcode == RC_OK)
    cout << "Error kod = RC_OK\n";
    }

    In a dialog application (MFC) I wrote the exactly the same code and get an error that I do not quit understand.

    "Unhandled exception at 0x779815ee in ArkenMfcApp.exe: 0xC0000005:
    Access violating location 0x008af845"

    Could it be some settings in den project Properties that differ between a command and dialog application?

    The bcStartPCI(0) is a command in 3rd party code (h, lib, dll)
    It is defined as:
    INT _PCI_LINKAGE_ bcStartPCI(INT);

    The only place where I find _PCI_LINKAGE_ is infront of other function and as the following 3 lines right after each other at the beginning of the h-file:
    #ifndef _PCI_LINKAGE_
    #define _PCI_LINKAGE_
    #endif

    I have no clue how it is implemented.
    Last edited by jangus; October 5th, 2011 at 09:25 AM.

  2. #2
    Join Date
    Sep 2004
    Location
    Holland (land of the dope)
    Posts
    4,123

    Re: Odd error.

    What does the debugger tell you while it is crashing ?

  3. #3
    Join Date
    Oct 2011
    Posts
    14

    Re: Odd error.

    I am not sure where I should look for more debug info.
    So where should I look?

    I noticed that when running in a command application the bcStartPCI(0) by itself writes (probably with cout) a line of text: "No BCPCI device is installed on the system".
    And at the moment the device is not installed.

    I put a breakpoint at the bcStartPCI(0) and cleared the Output window.
    Then when I steped past the line the following lines showed up in the Output window.
    'ArkenMfcApp.exe' : Loaded 'C:\Windows\SysWOW64\wintrust.dll', Cannot find or open the PDB file
    'ArkenMfcApp.exe' : Loaded 'C:\Windows\SysWOW64\crypt32.dll', Cannot find or open the PDB file
    'ArkenMfcApp.exe' : Loaded 'C:\Windows\SysWOW64\msasn1.dll', Cannot find or open the PDB file

    The Error list show nothing at all.

    Hmmm I also got another error window now. That one says:
    Run-Time Checl failure #0 - The value of ESP was not properly saved across a function call. This uis usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

    A continue after that produces the error message in my first post.
    Hope that was what you asked for.
    Last edited by jangus; October 5th, 2011 at 09:55 AM.

  4. #4
    Join Date
    Sep 2004
    Location
    Holland (land of the dope)
    Posts
    4,123

    Re: Odd error.

    Some info on how to work with the debugger.

    And at the moment the device is not installed.
    So you are trying to write data to a device that isn't there ? If that is true, a crash is understandable

    Hmmm I also got another error window now. That one says:
    Run-Time Checl failure #0 - The value of ESP was not properly saved across a function call.
    Google has a lot of hits on this error. Maybe you should check some out to see if it has something to do with your problem.

  5. #5
    Join Date
    Oct 2011
    Posts
    14

    Re: Odd error.

    Well Skizmo, I need to test the function as it is supposed to check if the hardware is present.
    The program crashes aso on the computer that has the hardware installed.

    I will check on google.

  6. #6
    Join Date
    Oct 2011
    Posts
    14

    Re: Odd error.

    There seem to be a lot of talk about _stdcall and _cdecl .
    I can not change the DLL as I do not have the code.
    So I changed the project/properties/C++/Advanced/Calling Convention. It was default set to __cdecl (/Gd) and I chnged it to __stdcall (/Gz) and that would not compile. I also tested __fastcall (/Gr).

    The error message in the compiler is:
    1>JFG_Gps.obj : error LNK2019: unresolved external symbol _bcStartPCI@4 referenced in function "public: bool __thiscall JFG_Gps::SearchGps(void)" (?SearchGps@JFG_Gps@@QAE_NXZ)

    I also some ide about declaring the functions as extern "C". Could not get that to work either.

  7. #7
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Odd error.

    Quote Originally Posted by jangus View Post
    There seem to be a lot of talk about _stdcall and _cdecl .
    That is not just "talk", it is a core part of what makes calling DLL functions work correctly.
    I can not change the DLL as I do not have the code.
    You have a header file that declares the DLL functions, correct? What does this header file state in terms of how the functions are declared.

    If not, then how are you calling the functions? Through LoadLibrary and GetProcAddress()?
    So I changed the project/properties/C++/Advanced/Calling Convention. It was default set to __cdecl (/Gd) and I chnged it to __stdcall (/Gz) and that would not compile. I also tested __fastcall (/Gr).
    Seems like you're just throwing stuff on the wall, hoping something sticks. When it comes to DLL's, you can't work that way -- you must know what you're doing at every step of the way and why you're doing it.

    First, do you know what a calling convention is (__stdcall, __cdecl) and how this impacts calling DLL functions that use parameters and return values?

    For example, if the DLL was built with the functions declared with __stdcall convention, then the application calling the DLL functions must call the DLL's functions using __stdcall convention.

    Do you know what extern "C" is supposed to do? If you're building a DLL from C++ source code, then again, this is a core part of understanding how to build DLL's from C++ source code and exporting functions.

    Regards,

    Paul McKenzie

  8. #8
    Join Date
    Oct 2011
    Posts
    14

    Re: Odd error.

    Quote Originally Posted by Paul McKenzie View Post
    You have a header file that declares the DLL functions, correct? What does this header file state in terms of how the functions are declared.
    Here is a cut from the header:
    Code:
    #ifndef __BC637PCI_H__
    #define __BC637PCI_H__
    
    #ifdef __cplusplus
    extern "C" {
    #endif
    
    #ifndef _PCI_LINKAGE_
    #define _PCI_LINKAGE_
    #endif
    
    //***************************************************************************
    // API Functions 
    //***************************************************************************
    INT	_PCI_LINKAGE_ bcStartPCI (INT);	
    void	_PCI_LINKAGE_ bcStopPCI (void);	
    
    #ifdef __cplusplus
    }
    #endif
    
    #endif // __BC637PCI_H__
    how are you calling the functions? Through LoadLibrary and GetProcAddress()?
    I do not have any of GetProcAddress or LoadLibrary in my code. The lib-file is added in Additional Dependencies and also visible under the project in the Solution Explorer.
    The header is #included in the calling files header and in the Solution Explorer.
    Here is some code from where I call the function
    [/quote]
    Code:
    #include "../stdafx.h"
    #include "JFG_Gps.h"
    JFG_Gps::JFG_Gps(): m_bActive(false)
    { 
    	m_bActive = SearchGps();
    }
    bool JFG_Gps::SearchGps(void)
    {
    	m_bActive = false;
    	INT errorcode = bcStartPCI(0);
    		m_bActive = true;
    	
    	return m_bActive;
    }
    Seems like you're just throwing stuff on the wall, hoping something sticks.
    Yes I do. It is the first time I have had problem with DLLs.

    First, do you know what a calling convention is (__stdcall, __cdecl) and how this impacts calling DLL functions that use parameters and return values?
    Yes some . It has to do with the order that the calling stack builds up and is cleared. But I can not say that I know exactly.

    For example, if the DLL was built with the functions declared with __stdcall convention, then the application calling the DLL functions must call the DLL's functions using __stdcall convention.
    Yes, I understand. As it is I do not know how the DLL where created.
    The calling convention for the project is __cdecl (/Gd).
    I do not have the command application here at the moment. It is at work. In that application the call to bcStartPCI worked. And the command application had the same calling convention if I remember right.

    Do you know what extern "C" is supposed to do?
    Well, no not exactly

  9. #9
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Odd error.

    Before doing anything, let's see exactly what the exported functions are.

    Take the DLL and use Dependency Walker. What are the names of the functions listed as exported.

    Regards,

    Paul McKenzie

  10. #10
    Join Date
    Oct 2011
    Posts
    14

    Re: Odd error.

    I suppose the "E"-list is the exported list?'
    The following where copied from the E-list with Ctrl-A followed by Ctrl-C

    Edit: some more info. All functions are marked with a C-icon.

    Code:
    bcAdjustClock
    bcClose
    bcCommand
    bcDebugOnOff
    bcDisRtcBatt
    bcEmulatorOnOff
    bcForceJam
    bcGPSMan
    bcGPSOperMode
    bcGPSReq
    bcGPSSnd
    bcGetDPReg
    bcGetReg
    bcMapPCI
    bcOpen
    bcPCICfg
    bcPCICfgOffs
    bcPCIDPTest
    bcPCIRdCtls
    bcPCIRdTm
    bcPCITestHarv
    bcPCIWrCtls
    bcPCIdpW1000
    bcPCIdpad
    bcPCIdpadc
    bcPCIdpw1
    bcPCIdpw1r2
    bcRdPciCfgSp
    bcReadBinTime
    bcReadDecTime
    bcReadEventTime
    bcReqDPOffs
    bcReqIrigSymbol
    bcReqManufData
    bcReqOscData
    bcReqOtherData
    bcReqTimeCodeData
    bcReqTimeData
    bcReqVerData
    bcSetBCDTime
    bcSetBinTime
    bcSetClkSrc
    bcSetDPReg
    bcSetDac
    bcSetDayLightFlag
    bcSetDis
    bcSetGain
    bcSetGenCode
    bcSetGenOff
    bcSetHbt
    bcSetJam
    bcSetLeapEvent
    bcSetLocOff
    bcSetLocalFlag
    bcSetMode
    bcSetPDelay
    bcSetPciCard
    bcSetRTC
    bcSetReg
    bcSetTcIn
    bcSetTmFmt
    bcSetUtcCtl
    bcSetYear
    bcSpecialBoot
    bcStartPCI
    bcStopPCI
    bcSyncRtc
    bcTestPktTime
    bcUnMapPCI
    bcWrtPciCfgSp
    bcYearAutoInc
    Last edited by jangus; October 6th, 2011 at 03:21 AM.

  11. #11
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Odd error.

    Quote Originally Posted by jangus View Post
    I suppose the "E"-list is the exported list?'
    The following where copied from the E-list with Ctrl-A followed by Ctrl-C
    OK, so the functions seem to be __cdecl and they are extern "C", so the header file seems to be correct. By default, calls use the __cdecl calling convention, so there is nothing to adjust.

    Let's get to this:
    The error message in the compiler is:
    1>JFG_Gps.obj : error LNK2019: unresolved external symbol _bcStartPCI@4 referenced in function "public: bool __thiscall JFG_Gps::SearchGps(void)" (?SearchGps@JFG_Gps@@QAE_NXZ)
    First, that is not a compiler error. That is a linker error. The error means that you're calling the bcStartPCI function, but the linker cannot find where this function is. Did you get an import library, along with the DLL? If you did, you're supposed to add the import library to the linker settings.
    Code:
    bool AClass::SearchGPS(void)
    {
    
    int errorcode = bcStartPCI(0)
    if(errorcode == RC_OK)
    cout << "Error kod = RC_OK\n";
    }
    If you did build the code, this doesn't tell us anything as to what your program is doing. You have this object called "AClass" -- who knows what was going on before any of this code was executed. Maybe "AClass" is not a valid object? Again, who knows.

    A proper test is to write a main() program, and the only thing you do is call the DLL functions. You shouldn't be creating classes and doing all sorts of other stuff. By adding superfluous code, you're increasing the chances that it's the other code you're adding that's causing the problem, and not the DLL.
    Code:
    #include "bc637pci.h"
    
    int main()
    {
       int errorcode = bcStartPCI(0);
    }
    That is all you need to do. What happens now (if you get this to compile and link)? Does it now behave correctly?

    Regards,

    Paul McKenzie

  12. #12
    Join Date
    Oct 2011
    Posts
    14

    Re: Odd error.

    While testing, as you said, I found out what probably where the problem.

    I feel really stupid to not have noticed.
    I am working on a new and clean computer to where I have copied only one set of each dll, lib and so on for this project. So I was sure I had the correct files.
    But the drivers that I got from the hardware manufacturer contained 3 different types .
    One 64-bit and one 32-bit version that I had no problem to distinguish between. But there where also, in the example files, one old version of the 32-bit.

    So I had by mistake and stupidity copied the new DLL (2009) and the old LIB (2004).
    When I sorted this out and started to use the correct files it worked as intended.

    But I must thank you both for helping me out with the problem. Your help have given me a bit of insight in DLLs and I intend to read me in on that topic.

    Thank you

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)