VS2008 C++ MFC Access Violation ONLY when stepping through debug mode

Question

Hi. This is crazy. It started happening in my main project, so I created a tiny sample brand-new project to reproduce it in and sure enough.. It does NOT happen in a sample project I created that is only a Win32 console app.

I'm running this on Win7x64, if that matters. VS2008 SP1.

Here goes. I create a small dialog app with a button. Put a breakpoint in the handler function for that button. The button handler function looks like this:

void CTestProjectDlg::OnBnClickedButton1()
{
    int i;

    i = 2;  // < breakpoint here
    i = 3;

}

Click the button, hit the breakpoint. F10 to step, and boom: "First-chance exception at 0x0398f77b in TestProject.exe: 0xC0000005: Access violation."

It gives me the option to Break or Continue. If I Continue, it just hits it again, only not "First Chance". Yes I have that exception checked in the Debug->Exceptions dlg.

If I Break, the call stack just shows me the line where the breakpoint is. If I F10 again.. I get the exception again, only now the callstack shows me in the _AfxDispatchCmdMsg() function, and my original OnBnClickedButton1() is not in the callstack anymore.

It doesn't matter where I put the breakpoint.

If, instead of F10, I just continue with F5, it works normally.

Now.. if I build a Release version and run in debugging mode: I hit the breakpoint, and all the pointers, variable values look normal. F10, and these turn to garbage. The this pointer is now zero. The m_csHello is now

However, in Release mode, an exception is not caught, and it all runs fine. The "hello World string gets displayed in the dialog box as it should.

I have put in an inquiry to see if some patch was installed on my box by the IT dept in the last day or two. This wasn't happening 2 days ago.

What do you think? Is VS2008 corrupted?

Thanks.

Edit: Additional Information. This does not happen if I build/debug the x64 platform. Only for Win32.
I also took a look at all of the hotfixes/security updates for VS2008 on the box. They are

• kb971092 and
• kb972222

Finally, I put the project on a different machine that has not been updated for the past 2-3 weeks. It works find on there, and it has these same VS updates installed.

I have also altered the code that is being stepped over for the purpose of this post. .. It is a simple integer assignment, no MFC involved.

At the moment I am in the middle of re-installing VS2008.

Answer 1

If it works in Release but not debug then I'd reckon you have an uninitialised variable somewhere. In debug it is automatically set to 0xcdcdcdcd (or a sub-portion thereof depending on variable size) which causes you to fail in Release you have whatever value was in memory already and perhaps that value prevents it from breaking ... Quite often an uninitialised variable like this is used as a loop bound and in debug you write through memory and overwrite something important which can LATER cause a failure. In release the value just happens to be OK but it may not always be the case.

As for your debugging in release don't worry that the this value looks like it is null. It most probably isn't but its very hard for the debugger to tell exactly where you are in code due to the optimisation process.

Answer 2

You say the same project compiles and runs just fine on a different machine with the same version of Visual Studio. The code looks fine, so yeah, it sounds like VS 2008 is corrupted and needs to be reinstalled.

Answer 3

The smart thing to do is (counter-intuitively) chuck all the breakpoints and such out. Rebuild your project (not an incremental build). The important thing is to start from a clean slate, grab the exception, and get a clean call stack and make sure that the build is accurate of the source files. You should also disable pre-compiled headers and such.

Answer 4

I'm also experiencing the same thing, again on the Win7x64, VS2008 SP1 development platform. My code is c++, WTL, ATL, DirectShow and various other libraries.

Windows update log reveals that there was a windows update on my machine at lunchtime. The problem only started occurring after lunchtime - with no project changes!

Damn you and your stupid automatic updates that break development environments m$!!! Shame on y'all!