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?

Solution 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);

Solution 2

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

char szInfo[50];

Comments

[IInspectable]

You failed to consider mismatching calling conventions.

[nvoigt]

@IInspectable 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.

[IInspectable]

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

[nvoigt]

@IInspectable 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.

[David Heffernan]

@IInspectable is trying to help. I cannot understand your prickly response, nvoigt.

[nvoigt]

@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.

[David Heffernan]

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 @IInspectable is a fine SO user who makes a lot of good contributions.

[IInspectable]

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.

[Admin]

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.

[IInspectable]

@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).

[Admin]

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

[Merlevede]

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

[user13500]

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