Ordinal Not Found in MFC DLL.

I am trying to port a VC++ 5.0 project to VC++ 6.0. The build went through fine (after VC++ informed me that the .dsp file is being converted). But when I try to run it, I get a message:

"Ordinal Not Found

The ordinal 977 could not be located in the dynamic link library MFCD42D.DLL."


This happens in Debug build only; the release build works fine.

I have read a PAQ which addresses a similar problem. There, the answer said that when using VC++6.0, you must distribute MFC42.DLL, OR statically link MFC through project settings. I can understand this in a situation where a distribution of an executable is involved, where the target computer may have a different environment.

What I cannot understand is, when I rebuild the whole project from scratch (after CLEAN, I do Rebuild ALL) in VC++6.0, why does this problem still arise? As far as I can see, there should be only one version of MFC DLLs lying around on my computer, so my situation does not seem to be addressed by the PAQ.

What am I doing wrong? When I port a project from VC++5.0 to VC++6.0, what should I be doing? What I actually did is like this:

a. From the project folder, I deleted Debug and Release folders completely.
b. Copied everything remaining to the new machine which has VC++6.0.
c. Opened the .dsw file.
d. Did a Clean, and then rebuild all.

Is something else needed to be done?

thanks,
stochastic
LVL 8
stochasticAsked:
Who is Participating?
 
ShaunWildeConnect With a Mentor Commented:
Hi I've just lookied at my version of mfc42d.dll (6.00.8447.0) and it does have ordinal 977 - though I can't remember how to work out what function it relates to.
0
 
ShaunWildeCommented:
I suspect it is loading the wrong mfc42d.dll (it is probably linking with the mfc42d.lib from VC6 but loading the mfc42d.dll from vc5) have a look for all the mfc42d.dll on your machine. You should be able to fix it by copying the correct mfc42d.dll into your debug directory.
0
 
ZoppoCommented:
Hi stochastic,

check which MFCD42D.DLL your debug executable uses (with dependency walker, i.e. right click on exe in explorer there should be a menu item 'View Dependencies' ... click on dependency walker's view menu item 'View Full Path' to see locations of DLLs used) and of which version it is.

ZOPPO
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
stochasticAuthor Commented:
ShaunWilde,

I'm afraid I had already checked for other mfc42d.dll's on my machine. There was only one, and I confirmed that it was indeed the one which VC6 installed. So this does not seem to be the answer.

I believe that the general convention on EE is not to post 'answers' (instead post them as comments) unless you are totally certain that your answer will work. Very often, even when the answerer is indeed certain, s/he still chooses to post it as a comment. That way, the question remains open, and other people, possibly with a better answer, get a chance. The asker can always convert a comment into an answer.

thanks anyway for your effort.

Zoppo, I am going to follow your suggestion and come back with a response.

- stochastic
0
 
stochasticAuthor Commented:
Zoppo,

I don't get the 'view dependencies' option in the context menu in my explorer. Is there something I haven't installed?

- stochastic
0
 
ZoppoCommented:
Hmm, not sure ... try to find 'DEPENDS.EXE' in the MicroSoft Visual Studio directories and start it (should register itself to appear in explorers context menu). On my system it's 'C:\Program Files\MicroSoft Visual Studio\Common\Tools\Depend.exe'
0
 
jhanceCommented:
>I believe that the general convention on EE is not to post 'answers'

No that's not the general convention.

There are too many expert "wannabes" running around and copying real expert comments and then posting that as their own "answer".  Many question askers don't recognize this tactic and award them the credit. So they are accumulating expert points using other experts comments as their own answers.

Anyway, I'd encourage you to revisit ShaunWilde's answer.  He's right.  One or more of the DLLs or link library (.lib) files on your system is out of date.  

Have you installed the VC++ 6 service pack 3?
0
 
stochasticAuthor Commented:
Zoppo,

Thanks, I found depends.exe as part of Visual Studio's tools. I am now working on your suggestion.

jhance,
I could see the potential merit in ShaunWilde's answer. However, I did say earlier that I had only one version each of the concerned .libs and .dlls, and those are the ones which VC++ 6.0 put them.

I am checking on the service pack. Will be back soon.

- stochastic
0
 
RONSLOWCommented:
could be that the lib file you linked with doesn't correspond.
0
 
chensuCommented:
ShaunWilde was right.

PRB: MFC Debug DLLs Are Not Compatible Between Versions
http://support.microsoft.com/support/kb/articles/Q190/4/87.ASP
0
 
ShaunWildeCommented:
Sorry you didn't like my answer - however whenever I have had this (or come across this) problem in the past this has always been the solution. If of course it isn't correct you have every right to reject it.
0
 
stochasticAuthor Commented:
ShaunWilde (and others),

I am genuinely hoping that your answer does turn out to be right. Many other experts seem to be supporting it, and also some kb articles I saw on MSDN (including the one chensu suggested). I will be happy to accept your answer as correct answer once I fix my problem.

The present situation is:
I installed VC++6.0 SP3, and it has still not solved my problem! The exact same problem persists. I have checked the versions of concerned .lib and .dll files. I have also checked that my computer contains only one occurence of each file, and that seems to be correct - the VC6 SP3 version.

I have also checked through dependencies like Zoppo suggested. All versions seem to be right. But obviously something still _is_ wrong.

I am going to clean up my project folder completely, and create the project up from scratch, and add the source files to it. That should fix it, I guess. I wonder whether the CLEAN command omits cleaning something that causes this. Such as, say, .pch files?

Anyway, I will come back with more status updates soon, hopefully reporting that the problem is gone. I would only be too happy to award you the points.

I rejected your answer not because it might be wrong, but because it was presuming that the problem was solved, which wasn't true at that point. I wanted to get the benefit of others' answers too. Hope you understand.

To everyone: thanks folks. Regardless of whether the suggested remedies work or not, there is always education in your comments.

- stochastic
0
 
stochasticAuthor Commented:
ShaunWilde,

I think your answer was right after all. Although my problem is _still_ not fully solved, I could trace it to this: in my project I was using third party code, which had been already built into .libs, with VC++5.0, and therefore the problem continued despite my initial attempts. I have rebuilt those third party pieces again in VC++ 6.0, and things are progressing. I think I will get it working fully soon.

Happy to grant you the points.

I must say thanks to everyone else who, while echoing your solution, added further useful information.

- stochastic
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.