0xC0000005: Access violation executing location 0x00000000

Question

I'm writing an MFC project that try to call a function in the DLL which will return some information in a string. The function in the DLL is as follows:

int GetInfo(char* Info)

The function will return 0 if success. Information will be returned in the string parameter. The calling routine is as follows:

typedef int (WINAPI *FUNC1)(char* szInfo);


HINSTANCE hinstLib;
FUNC1 GetInfo;
char szInfo[50];

hinstLib = LoadLibrary(TEXT("DevInfo.dll"));

// If the handle is valid, try to get the function address.
if (hinstLib != NULL) 
{ 
    GetInfo = (FUNC1) GetProcAddress(hinstLib, "GetInfo"); 

    // If the function address is valid, call the function.
    if (NULL != GetInfo) 
    {
        if((GetInfo) (szInfo)) // Error here!!
        {
            AfxMessageBox(_T("Error Reading"));
        }
    }

    FreeLibrary(hinstLib);
} 

This code does not have error in compiling and linking. When executing, it will return the error of "Access violation executing location 0x00000000" at the location stated above. Can anyone advice?

---

EDIT: The OP reports (in a comment to one of the answers below) that in this case:

"The error was due to the called function in the DLL which needs other dlls to be present."

Palatial

int WINAPI(char*) and int(char*) are not the same thing. Your function shold be at least prototyped as int WINAPI GetInfo(char*) – Minuet

Are you sure the error is there, and not in the GetInfo function? – Raimes

What does the debugger show as the call stack etc when the exception is thrown? – Tilsit

@EmilioGaravaglia I do not have the DLL code. Thus can't change the function. I have tried changing the typedef int (WINAPI FUNC1)(char szInfo) to typedef int (FUNC1)(char szInfo) and still getting the same error. – Palatial

@Tilsit The call stack is shown as 00000000() [Frames below maybe incorrect and/or missing] DevInfo.dll!002711eb() – Palatial

@user2845698: Ok, try viceversa: don't use WINAPI in your declarations – Minuet

Answer 1

You tried to write to (or dereference) a NULL pointer. As you checked all possible NULLs in your calling code, the error most likely is in your called code.

If you checked your called code and cannot find a reason for a null reference exception there either, consider that you may have missed to match the calling conventions correctly. The type of your function pointer should be EXACTLY the same as in your library:

For int GetInfo(char* Info) the typedef should be typedef int (*FUNC1)(char* szInfo);

Cicely

You failed to consider mismatching calling conventions. – Mulholland

@Mulholland No, I considered. And I left it out because all kind of weird stuff happens if you mismatch, but this would be the first time I see someone actually get a readable error from stack unbalancing. Also please note that I said "most likely" because without the called code, it's a guess at best. – Cicely

What would be an unreadable error then? And what does the readability have to do with the stack anyway? – Mulholland

@Mulholland This is not a discussion board. If you don't like that I don't repeat other peoples solutions AND you don't make the post better by simply editing it AND don't provide something helpful yourself... I wonder why you are here. Anyway, I'm not here to gather downvotes, if nobody upvotes, I'll simply delete it and let other people help the guy. – Cicely

@Mulholland is trying to help. I cannot understand your prickly response, nvoigt. – Parra

@DavidHeffernan I don't like people that downvote and critizise without making an effort to actually improve on it. If my answer was flat out wrong or he had written a better answer or helped the original poster in any way, I would think different. But he didn't. At the time of our comment, the post was at "-1" which I think is totally unwarranted just because I did not repeat what others already said. – Cicely

I think your answer would be better if it detailed the calling convention mismatch. It doesn't matter if others have said it in the comments. You should state it here for completeness. The fact that somebody has not written their own answer in no way disqualifies them from commenting on others. You've no idea who actually downvoted. I would say that @Mulholland is a fine SO user who makes a lot of good contributions. – Parra

To match a calling convention you absolutely must specify the calling convention. Your function signature and typedef pick up the default calling convention. This can be different between the .dll and the executable loading it. – Mulholland

I don't have the code in the DLL as it was given by others. Have changed the typedef and it doesn't help. Call stack error is written in my comment above. – Palatial

@user If you don't have the source code for the .dll, load it up in Dependency Walker and find the function you want to import. It's decorated name will tell you the calling convention (see Name Decoration). – Mulholland

Thanks for all your advice. The error was due to the called function in the DLL which needs other dlls to be present. – Palatial

Answer 2

It is also possible that more than 50 characters are being written to the buffer (szInfo):

char szInfo[50];

Titanium

If you're not sure about the answer, you should leave a comment – Beginning

@Merlevede: Believe you misread Jay's intention. It is meant as: "One possibility among several." I.e. In addition to the other answer. – Cobham