Odd error.

[jangus]

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.

[Skizmo]

What does the debugger tell you while it is crashing ?

[jangus]

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.

[Skizmo]

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.

[jangus]

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.

[jangus]

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.

[Paul McKenzie]

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

[jangus]

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:

#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]

#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

[Paul McKenzie]

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

[jangus]

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.

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

[Paul McKenzie]

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.

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.

#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

[jangus]

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