Can't step into MFC source


I am using MSVC++ 4.2 under Windows NT4.0 since it became available a couple years ago and I was always able to step into MFC functions using F11. A couple days ago, I had to reinstall the program because some third party memory checker screwed up my \msdev directory.

I did a Custom installation and I have the MFC sources on my hard disk ( size of \msdev > 206MB ). The "Directories" tab in the Tools/Options dialog with the "Source files" selected shows the correct path to my \msdev directories:
D:\MSDEV\mfc\src                               ( containing 279 files )
D:\MSDEV\mfc\include                        ( containing 75 files )
D:\MSDEV\crt\src                                 ( containing 784 files )
D:\MSDEV\crt\src\intel                         ( containing 53 files )

The Environment tab in the System Properties has the following user variables:
include          d:\msdev\include;d:\msdev\mfc\include;%include%
lib                  d:\msdev\lib;d:\msdev\mfc\lib;%lib%
MSDevDir    D:\MSDEV
path               D:\MSDEV\BIN

However, I cannot step into MFC source. The program let me step into an assembly runtime routine like
strcpy() but it doesn't let me step into MFC functions. It just steps over. It doesn't let me set a breakpoint within a MFC function neither. It just beeps at me! If I set a breakpoint outside of a function and then start the debugger I get the usual message "One or more breakpoints cannot be set and have been disabled. Execution will stop at the beginning of the program." After the click on OK, the program opens the file D:\MSDEV\mfc\src\APPMODUL.CPP, which is the file on my HD and not the file on the CD.

Is there anything that I should check in the "Project Settings" dialog like under the "C/C++ tab / Listing Files" ? Right now "No Listing" is selected.

I need expert advice so that I can step into MFC source again.

Eric Jucker
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

When you build an MFC project, the linker pust some information about MFC into your executable and gets the rest from the MFC PDB files. If there's a mismatch, however tiny, the debugger will fail to step into the MFC sources.

You need to make sure that the PDB files you're loading match, exactly, the MFC libraries and/or DLLs that you're using. If even one of them is off, you'll notice the symptoms you report here.

You also need to make sure that your own executable doesn't have stale information built into it. That's possible, since you don't mention doing a full, complete, clean rebuild and you've updated and replaced MFC since the time things worked properly. Do a complete rebuild of _everything_ you build in your project, and do it by erasing your PCH and temporary files manually.

The KnowledgeBase article Q121556 addresses the problems that can cause your problems.

Selecting a listing file causes the compiler to emit assembly or mixed assembly/object code for your source files; it isn't germain to your problem.

.B ekiM


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ericj040697Author Commented:

I did what you recommended, but no success.
I also created a new MFC test project with AppWiz, accepting all defaults, compiled, and debugged, to see if it works with a vergin, but I can't step into MFC code.

I'm doing it again on my project and here are the steps:
manually deleting all files in the debug directory.
delete the ModEd.aps and the ModEd.ncb files
set the ModEd.mdp file to size 0
Open the ModEd.mdp file in the Developer Studio
Ckeck the Settings dialog / CC++ / Precompiled Headers, click the "Create Precompiled Header file (PCH)" and type the name ModEd.pch
Click on "Rebuild All."
Get the message "The source files D:\abl_new\StdAfx.cpp and D:\abl_new\ModEd.cpp are both configured to produce the output file "D:\abl_new\Debug\ModEd.pch." The project cannot be built."
So, I click the Reset button which enables the radio button "Use precompiled header file (PCH)" through header stdafx.h
Rebuild All
Again, get the message "The source files D:\abl_new\StdAfx.cpp and D:\abl_new\ModEd.cpp are both configured to produce the output file "D:\abl_new\Debug\ModEd.pch." The project cannot be built."
So, I click on "Automatic use of precompiled header." (What else can I do?)
Rebuild All. This time we have a lift off: it starts compiling.
After "Rebuild All" is done, I set a breakpoint on top of InitInstance() and start the debugger. It stops at the breakpoint. However, it doesn't let me step into the MFC functions.
Ok, I don't have the *.pdb file because the default settings disables it.
I stop the debugger and open Settings dialog, click on "Generate browse info" and "Build browse info."
Manually delete all files in the debug directory and then "Rebuild All" again.
Half an hour later, I hit F5. It stops on top of InitInstance(), but...

Mike, I think you should have a look at my *.mak file. I know, you are going to watch the Stars/Red Wing game. So, I increase the points by another 150.


You don't have which *.PDB file? The default setting of what disables the PDB file?  That doesn't make any sense to me; a default project from AppWizard includes a debug target that gives the linker the /DEBUG option and the /PDB option, and the compiler the /Zi option, and that causes the generation of debug info that's baked into a PDB file.

Are you building to statically link to MFC, or link to MFC in a DLL?

If you've got problems with your PDB file not building correctly, the rest of your project is hopeless. The error message you're receiving means exactly what it says: you've configured the settings for your project to produce a STDAFX.PCH file by building two different source files, and that's not right.

I don't know why you changed the name of the PCH file or how it was generated. That has nothing to do with your debugging problem, though it will prevent you from getting a clean build.

.B ekiM

Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

ericj040697Author Commented:
Sorry about the confusion. You mentioned the PDB file and I meant the ModEd.BSC file.

The ModEd.PDB file is generated while compiling. I also have a ModEd.PCH file created
through header stdafx.h.

I am building to statically link to MFC.

Please, keep in mind that the dreaded problem is also in a clean and untouched AppWizard project.


If it's happening an untouched AppWizard project, then you certainly know there's some mismatch between the *.LIB files you're linking to while building, the *.DLL files you're loading as you execute, and the *.PDB files you're finding while running under the debugger.

.B ekiM
If you're statically linking, then the problem is narrowed down just a bit more: you know that the LIB and PDB files you're building with don't match.

.B ekiM

ericj040697Author Commented:
You are right. I created an AppWizard test project, selected "Use Shared DLL", built all, and bingo: I can step into MFC.

What has to be done that the LIB and PDB files match?

Some of the non-experts around here would tell you to reinstall. I guess that's the brute-force method of fixing the problem.

But, if it were me, I'd go to the LIB directories and try to figure out which files weren't matched. The PDB and LIB files you see for MFC should all match exactly in date and time. If any are off, you should replace them all from your CD.

You also might be picking up rogue versions of different libraries if your library path is really messy.

.B ekiM

ericj040697Author Commented:
Reinstall what? The Development Studio? I did that brute force method many times in the
past few days. The files NT4.0 OLEAUT32.DLL / STDOLE2.TLB installed by the NT4.0
Setup are newer than the  files on the Visual C++ Professional Subscription (Version 4.2).
I tried installations of DevStudio with overwriting and without overwriting. Both types of
installations don't let me step into MFC source.

I guess the problem is somewhere in the WINNT directory in some dll because everything
worked fine for years until I deinstalled that (damned) memory checker. I still have that little memory leak which is hopeless to find without stepping into MFC. The end of the month is coming soon and I have to deliver.

The brute force method left is now reinstall NT: not repair (I tried that earlier), but installing
a fresh OS with all the consequences. That will work for sure.

Thanks for helping anyway.

It's remotely possible that you have a bad version of IMAGEHLP.DLL. But if that were true, I think you'd find you couldn't step into anything or see any stack traces at all.

Do all the files in your installed MFC\LIB directory match for both date and time? Do you see any warnings in the debug output window in the IDE when you start your program under the debugger?

.B ekiM

ericj040697Author Commented:
The problem is solved: I can step into MFC again. I just had to reinstall a new OS. That's all.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.