Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.
Solved
Memory cannot be referenced error
Posted on 2001-08-15
Hi,
I have this C++ codes that I cut and paste from a working program, but to my dismay gives me the following run time error:
The instruction at "0x0012f9de" referenced memory at "0x0000000000". The memory could not be "read".
Click on OK to terminate program
Click on Cancel to debug
Pls help.
-------------------
// Source code is as follows:
typedef WORD (*OPEN)(WORD, BYTE*, WORD*)
....
OPEN my_open
BYTE msg[256];
WORD rlen;
WORD rcode;
hDLL = LoadLibrary(_T("myopen.dll
if (hDLL!=NULL)
{
my_open = (OPEN)GetProcAddress(hDLL,
if (my_open!=NULL)
{
// Run time error traced to below call
rcode = (my_open)(0, msg, &rlen);
}
}
----------
I have this C++ codes that I cut and paste from a working program, but to my dismay gives me the following run time error:
The instruction at "0x0012f9de" referenced memory at "0x0000000000". The memory could not be "read".
Click on OK to terminate program
Click on Cancel to debug
Pls help.
-------------------
// Source code is as follows:
typedef WORD (*OPEN)(WORD, BYTE*, WORD*)
....
OPEN my_open
BYTE msg[256];
WORD rlen;
WORD rcode;
hDLL = LoadLibrary(_T("myopen.dll
if (hDLL!=NULL)
{
my_open = (OPEN)GetProcAddress(hDLL,
if (my_open!=NULL)
{
// Run time error traced to below call
rcode = (my_open)(0, msg, &rlen);
}
}
----------
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
3
-
2
- +2
8 Comments
May be problem in name of function from dll. For know exectly all name of functions I use TDump utility of Borland.
> May be problem in name of function from dll. For know exectly all name of functions I use TDump utility
of Borland.
I don't think this is the problem, because the GetProcAddress() would return NULL in this case...
I suspect the problem coud be in the variable msg. You are reserving 256 bytes of the memory for it. Are you sure that your DLL function is accessing only that range of memory?
Do you have access to the myopen.dll code?
of Borland.
I don't think this is the problem, because the GetProcAddress() would return NULL in this case...
I suspect the problem coud be in the variable msg. You are reserving 256 bytes of the memory for it. Are you sure that your DLL function is accessing only that range of memory?
Do you have access to the myopen.dll code?
Nothing wrong with the parameters, strange thing is it can work in debug version but crashes in release version, any idea?
O, it is difference between Debug and Release version in VC. There are many Q in EE about this issue, but I work in BC and can't help you. Sorry.
The problem could be in the implementation of the function
in the DLL. One of the differences between Realese and
Debug, is that Debug version gives you some protection, such as "preparing" the stack with padding characters.
It could be that the function you call, is has a fault
which causes it not to run properly in a Release version.
in the DLL. One of the differences between Realese and
Debug, is that Debug version gives you some protection, such as "preparing" the stack with padding characters.
It could be that the function you call, is has a fault
which causes it not to run properly in a Release version.
I've just read the Etiquette page, and I wanted to
apologize on sending an Answer, instead of a Comment.
Udil
apologize on sending an Answer, instead of a Comment.
Udil
oohchild,
Do you still need help with this?
The answer is almost certainly that you have reversed the correct order of parameters.
Perhaps there is an old version of myopen.dll that used different parameter type or sequence. If that copy of myopen.dll is in the Release directory, it would be called. While the good one (in your Debug directory) would be working fine for debug builds.
-- Dan
Do you still need help with this?
The answer is almost certainly that you have reversed the correct order of parameters.
Perhaps there is an old version of myopen.dll that used different parameter type or sequence. If that copy of myopen.dll is in the Release directory, it would be called. While the good one (in your Debug directory) would be working fine for debug builds.
-- Dan
Featured Post
Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!
Learn how Concerto can help you.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Often, when implementing a feature, you won't know how certain events should be handled at the point where they occur and you'd rather defer to the user of your function or class. For example, a XML parser will extract a tag from the source code, wh…
Many modern programming languages support the concept of a property -- a class member that combines characteristics of both a data member and a method. These are sometimes called "smart fields" because you can add logic that is applied automaticall…
The viewer will learn how to pass data into a function in C++. This is one step further in using functions. Instead of only printing text onto the console, the function will be able to perform calculations with argumentents given by the user.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.
Suggested Courses
Course of the Month8 days, 22 hours left to enroll
721 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.