0xC0000005 Access Violation MFC42D.DLL Windows XP


I've an application that runs very well in W2K (not tested in prior versions) but when I try tu run it in WXP it just crash. I don't get any error, just crash. When debugging, I get this:

First-chance exception in ctsmgt.exe (MFC42D.DLL): 0xC0000005: Access Violation.

I've read a lot on how to try to overcome this. Some say to put try/catch blocks, some others just to ignore the exception. I've tried both but it keeps crashing.

I'm really desperate and stuck here, I don't know what to do. Any advice will be greatly, greatly appreciated.

Who is Participating?
CetusMODConnect With a Mentor Commented:
PAQed with points refunded (500)

Community Support Moderator
>>I've read a lot on how to try to overcome this. Some say to put try/catch blocks, some others just to ignore the exception

What functions are on the call stack when the exception is raised ? Also what is the version of mfco42d.dll ?

You can try to reapply the latest service pack for VC.

Are you running your application on Win XP-SP2 (Service Pack 2 ) ? IF SO THEN also check one more thing to test if MFC42.dll causing the problem..
Copy mfc42.dll from system32 from 'NON SP2 XP' machine to your applications executable directory. If you wish to debug you I believe the file is mfc42D.dll you will need to copy to your debug directory and check your application .

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

>>First-chance exception in ctsmgt.exe (MFC42D.DLL): 0xC0000005: Access Violation.

'First-chance exception in xxx...' just means that a function from within the 'xxx' caused an access-violation exception that was handled successfully inside the SEH frame that was active when the exception occurred. You can think of it being the same as if you use code like this:

long l;

__try // set up current SEH frame
CopyMemory ( &l, 0, sizeof ( long)); // read from 0x00000000
__except( EXCEPTION_EXECUTE_HANDLER) // handler for current frame
puts ( "We knew that this would go wrong...");

So let's hope that the MS progrmmer knew what they were doing ;-)

(Additional info: MS KB Article Q105675)

The article can be found at http://support.microsoft.com/support/kb/articles/q105/6/75.asp 

A first chance exception is called so as it is passed to a debugger before the application 'sees' it. This is done by sending a 'EXCEPTION_DEBUG_EVENT' to the debugger, which can now decide whether it is passed to the apllication to handle it or 'ignore' it (e.g. like an 'EXCEPTION_BREAKPOINT' aka 'int 3'). If the exception isn't handled, it becomes a '2nd chance' exception, the debugger 'sees' it the 2nd time and will usually terminate the program (without using a debugger, these exceptions end up at 'UnhandledExceptionFilter()' which will also signal the exception to the user with one of these 'nice' message boxes and terminate the program, also...)

In short: This message is only generated by a debugger & you can safely ignore it...
ObiRenoKenobiAuthor Commented:
I'm looking for a WinXP NO SP2 MFC42D.DLL but can't found one. I tired to use one from W2K but was not a good idea hehehe.

As for the other comment, I read that of ignoring the debug error and just run it in release mode, but, my application crashes also in release, and no error is giving to me. So I think I may not be able just to ignore it :(
ObiRenoKenobiAuthor Commented:
Hi again!

I've returned with more information. The problems seems to arise when a call to _AFX_INLINE CStringData* CString::GetData() const
is made. It's a bit strange, because of this: I've a function that calls the
void CString::FormatV(LPCTSTR lpszFormat, va_list argList) from STREX.CPP, this in turn, calls GetBuffer(nMaxLen), the funny thing here, is that those functions are called several times, and always, de GetBuffer function goes to VSPRINTF.C, every single time it goes there EXCEPT when is crashing, a debug breakpoint was established in that function call, and whenever it enter (using F11 key) it goes to VSPRINTF.C, but when I enter the function just a step before it crashes, it goes to LPTSTR CString::GetBuffer(int nMinBufLength) and in that function, in the first IF (when it try to do GetData()-nRefs) it goes to _AFX_INLINE CStringData* CString::GetData() const, and right there is when the exception arises and the program crashes.

One thing that I must mention, I don't know if it is important, but nonetheless I will tell you. In all the cases when GetBuffer is called, except when it crashes, the variable m_pchData have something, but... when it's about to crash, the debuger says:
m_pchData      CXX0030: Error: expression cannot be evaluated
and following the debug, when it enters the_AFX_INLINE CStringData* CString::GetData() const, it says:
m_pchData      CXX0069: Error: variable needs stack frame

I don't know why this is, nor if it is important o have anything to do with my problem, but I write down here for your information.

Any new ideas? Thanks!
Very wild guess - have you had a .net update recently i.e. it came around November/December last year but you've only just updated your system with it?  Also, is your system set up for .net 1.1 or .net 2.0 or neither?
Hey ObiRenoKenobi ,

I'm having the same issue as well. Did you resolve it? If so, how?

Thanks a ton.
ObiRenoKenobiAuthor Commented:
Hi! Sorry for posting till now. I resolved the issue but it was not on the code. The problem was that we were trying to use the application with an Oracle 8i lib, but trying to connect with an Oracle 9i!!! When we switched to Oracle 8i, all started to work... a difficult to track problem, but a silly one.

Thanks to all for your help!
Hey ObiRenoKenobi,

Kindly tell me which oracle 9i lib file to use?

All Courses

From novice to tech pro — start learning today.