locked
First-chance exception RRS feed

  • Question

  • I am porting a large vc6 app to vs2005.  It is going well for the most part.   But I have noticed one unusual thing.

    While running my app thru the debugger, I bring up a certain screen in my app.  Once  the screen displays, the app is idle, waiting for more input.  But in the Output window of the debugger, I am getting the following error at about 100 per second!!!

    First-chance exception at 0x77e26806 (USER32.DLL) in PCSMain.exe: 0xC0000005: Access violation writing location 0x6122a218.

    If I let the app ( PCSMain.exe) just sit there, it will eventually run out of memory in a few hours, I assume because of this exception.  I can watch the memory in use rapidly increase in the Task Manager.  While this is happening, I can still use the app, so I assume that the os is handling the exception.

    If I run the app directly (not thru the debugger), and do the same thing, then there is no memory problem at all.  I can let it sit there for hours, and the Task Manager shows no memory usage increase at all.

    I did go back and run my app under vc6 in debug mode as well to see if the problem has always existed and I never noticed.  But doing this showed no memory problems at all either.

    So, I guess my question is, is this a real problem that I have, or is it some quirky Visual Studio / debugger thing?

     

    Thursday, July 6, 2006 7:46 PM

Answers

  • Until you've proven that it's a debugger issue, you have to assume that it's an application issue.

    Have you tried to locate the exact source of the exception?  It's likely that it's an over-indexed object on the heap, and the difference in behavior is due to changes in the heap implementation between VC6 and VC8.

     

    Thursday, July 6, 2006 10:35 PM
  • Apparently VC8 put the string literal in read-only memory (as it's allowed to by the standard) but VC6 didn't.  That'd explain the exceptions.
    Monday, July 10, 2006 4:20 PM

All replies

  • I'm guessing this is a debugger bug.  Bugger!  It is pretty unusual for an app to trap an Access violation exception.  I'd have to guess that the author of the original app did this to squelch a bug in his/her software.  As a consequence, the debugger hasn't been exactly proved at handling SEH exceptions, especially at a rate of 100/second.  Please don't hesitate to report this issue here...

    Thursday, July 6, 2006 9:31 PM
  • Until you've proven that it's a debugger issue, you have to assume that it's an application issue.

    Have you tried to locate the exact source of the exception?  It's likely that it's an over-indexed object on the heap, and the difference in behavior is due to changes in the heap implementation between VC6 and VC8.

     

    Thursday, July 6, 2006 10:35 PM
  • Thanks for the hint Carl!

    I had assumed that my app did very little processing while the app was idling (OnIdle() method only updated the app's timestamp in the status box).  But I did find some other, more extensive, processing when a separate thread is idling.  In it was the following code:

     

    LPTSTR parmStr = "0123456789012345678901";

    i = GetWindowText(aChildWnd, parmStr, sizeBuffer);

     

    I changed the code to the following:

    const int sizeBuffer = 75; 

    char parmStr[sizeBuffer+1]; 

    i = GetWindowText(aChildWnd, parmStr, sizeBuffer);

    and the exceptions went away.

    I still don't know why the exceptions only happened when the app was run thru the debugger and not when it was run directly.  This happened with both Debug and Release versions of the app.   I guess it has to do with the memory management changes from vc6 to vc8 in some way.


     

     

    Monday, July 10, 2006 1:50 PM
  • Apparently VC8 put the string literal in read-only memory (as it's allowed to by the standard) but VC6 didn't.  That'd explain the exceptions.
    Monday, July 10, 2006 4:20 PM
  • That makes sense.  Thanks for the help, Carl!
    Monday, July 10, 2006 4:24 PM