Unhandled exception...:Access Violation
Minh C. Tran -- mct@znet.com
Saturday, March 15, 1997
Environment: VC++ 4.2b, NT 4.0
I am writing an OLE-COM client application and everytime I exit or close my
application I get the following access violation:
Unhandled exception in (NTDLL.DLL):0xC0000005:Access Violation
Here is the cut down version of my application:
hr = ::CLSIDFromProgID(...);
hr = ::CoGetClassObject(...);
pClf->CreateInstance(...);
pUnk->QueryInterface(...);
Mike Blaszczak -- mikeblas@nwlink.com
Tuesday, March 18, 1997
[Mini-digest: 3 responses]
At 15:46 3/15/97 -0800, Minh C. Tran wrote:
>Environment: VC++ 4.2b, NT 4.0
>I am writing an OLE-COM client application and everytime I exit or close my
>application I get the following access violation:
>Unhandled exception in (NTDLL.DLL):0xC0000005:Access Violation
>Here is the cut down version of my application:
>hr = ::CLSIDFromProgID(...);
>hr = ::CoGetClassObject(...);
>pClf->CreateInstance(...);
>pUnk->QueryInterface(...);
Works fine on my machine.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
One is too many and a million is not enough.
-----From: Katikareddy RajaMohan Reddy
Minh C. Tran wrote:
>
> Environment: VC++ 4.2b, NT 4.0
>
> I am writing an OLE-COM client application and everytime I exit or close my
> application I get the following access violation:
>
> Unhandled exception in (NTDLL.DLL):0xC0000005:Access Violation
>
> Here is the cut down version of my application:
>
> hr = ::CLSIDFromProgID(...);
> hr = ::CoGetClassObject(...);
> pClf->CreateInstance(...);
> pUnk->QueryInterface(...);
I guess you're not releasing the interface.
Hope this helps,
Cheers,
-Reddy
-----From: "Hemanta Banerjee"
Hi ,
Infact im also facing the same assertion failure for no apparent reason.
I have even tried checking with Bounds Checker 4.0 professional edition
and that does not report any problems.If u can find out why please send
me the reason.Myu mail address is .
Bye,
Hemanta Banerjee.
> Environment: VC++ 4.2b, NT 4.0
>
> I am writing an OLE-COM client application and everytime I exit or close my
> application I get the following access violation:
>
> Unhandled exception in (NTDLL.DLL):0xC0000005:Access Violation
>
> Here is the cut down version of my application:
>
> hr = ::CLSIDFromProgID(...);
> hr = ::CoGetClassObject(...);
> pClf->CreateInstance(...);
> pUnk->QueryInterface(...);
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Office :- Residence :-
HCL Technologies Limited, #17, Sriramnagar 1st Cross,
50-53 Greams Road, Thiruvanmiyur,
Madras - 600 0006. Madras - 600 041.
Ph :- (91)-(44)-8279140,8279312 (91)-(44)-4913160 PP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Richard Morris -- richard@softwaremachine.com
Tuesday, March 25, 1997
At 08:24 PM 3/18/97 -0800, you wrote:
>[Mini-digest: 3 responses]
>
>At 15:46 3/15/97 -0800, Minh C. Tran wrote:
>>Environment: VC++ 4.2b, NT 4.0
>
>>I am writing an OLE-COM client application and everytime I exit or close my
>>application I get the following access violation:
>
>>Unhandled exception in (NTDLL.DLL):0xC0000005:Access Violation
Here is a summary of some other responses and solutions people have found to
the problem you are facing. It looks like it is an MFC bug, but there are
ways to
work around it. Rumor has it that it no longer rears its ugly head in VC++ 5.0.
Here you go:
I have had some semblance of success with the problem. But before I go
into my solution, a couple comments on the responses I got.
"GoroKhM1" wrote:
> a) We found out that we had 'pure' timing problems whenever we
>encountered these type of problems. All I would have is ??? in my debug
>window assembler code.
> b) If you find these symptoms, try adjusting the PageTimeOut settings
>for your ODBC driver. I don't know what type of database you are using,
>but looks like you are encountering this in Access (.mdb) files. If not
>do NOT read ahead.
> c) A wait before you call DB->Close() would really help the ODBC driver
>to wind their threads.
>
> This may not be a neat soultion but waiting for a few milliseconds
>before winding the app down did solve the problem for us.
Timing is close to solving the problem. You suggest a pause in the program
before shutdown. I'm normally loathe to do something of that nature unless
I'm controlling hardware that has such considerations built in. For
something strictly software that depends on thread interaction, I don't
think you can ever get a pause to work 100% of the time. However, I was
about ready to do this with the problem. As it was, I didn't.
-----------
MarkG@usa.net wrote:
>I had similar problem with DAO: _sometimes_ crash on exit.
>KB Q153897 solved it and may give you an idea.
>
>In my case framework unloads MSJT3032.DLL (for DAO) _before_
>database close.
Thank you for that one. I had rummaged through my MSDN thoroughly to find
info on the problem, but to no avail. After I plugged the Q153897 into the
search, the January 97 CD came up telling me there was nothing there by
that number. It was on the Web, but I didn't scan that as thoroughly. Now
the mystery is why that's not on my CD. I will, however, take the advice
of Q135897 in the future unless something in VC5.0 cures it. (See next note)
---------
riddell@kudos.net (codeware) wrote:
>Get the latest version of the compiler. I had the same problem as you are
>reporting. This week I received VC version 5 in the mail and after
>recompiling the error went away.
It's on its way to me. When it arrives, I may test this some more.
-------------
"Doug Brubacher" wrote:
> I ran into similar problems to what you are seeing and resolved it by
> making my database object a pointer and explicitly new-ing and
> delete-ing it. I think I had to play with the location of the new and
> delete but since I do not have the code in front of me I can not give
> you a definite answer.
>
> I hope this helps, and does not fall into that red-herring category of
> solutions.
Regrettably, I didn't mention that the code I posted to the list was not
how it started out. It started the way you suggested. I switched to a
global instance to a CDatabase object as a shot in the dark to cure the
problem. I'm guessing that it was the positioning of the new and delete
that actually cured your problem.
------------
Mike Blaszczak wrote:
>
>>Mike B. will probably point out that I'm an idiot and I missed some
>>"obvious" documentation 8-), but idiot or genius, I need to figure this out.
>
>I grepped the archives that I have here at home, and I can't find any
>point where, in the history of the list, I called someone an idiot. As a
>result, your comment seems like unjustified defamation. I guess I'm obliged
>to give you the benefit of the doubt, though, and try and answer your
>question anyway.
I never said you DID call someone that and I apologize if I conveyed that.
You can certainly call me an idiot if I missed some clearly posted solution
to the problem.
>It would really help to see the exact stack trace and hear something about
>the state of the pertinent variables when the crash happens. Just because
>the trace is shallow doesn't mean it's meaningless.
This is true. I regret that I assumed it was. I didn't note the stack
position and now have to go back and retrofit my program with the bug to
get that trace.
>Odds are that you're using the CDatabase object before it's been initialized,
>or after it's been shut down. Global objects construct and destruct with
>special rules that are described by the C++ language unstandard. The compiler
>follows this part of the unstandard very closely. You need to make sure
>what you're doing falls well within those rules.
>
>One rule that could be affecting you is that a global object isn't guaranteed
>to be constructed until some code in the module where it's declared actually
>runs. Because of this rule, it's possible that you're using your object
before
>it's been constructed. Since the C++ unstandard has similar rules for
>destruction, it's possilbe that you're destroying the object
I really regret not having mentioned that I tried this both as a global
instance and as a pointer where I explicitly controlled the ctor/dtor pair
besides CDatabase::OpenEx and CDatabase::Close(). I guess I had already
cleared it in my own head that the use of a global instance wasn't the
problem, so I didn't mention it. My ommission led to confusing both you
and Doug (above) about the nature of my code.
>>(Richard Morris -- in another post to the list -- seems to have
>>had the same problem with threading and DAO, so there is
>>something to this.)
>
>You're making quite an invalid jump. DAO is well-documented to not be
>safe to use across threads, period. If someone is trying to do that,
>they can expect nothing but trouble. The documentation says:
>
> "DAO itself is not multithreaded, so you can't use the
> MFC DAO classes in multiple threads. Confine your
> DAO code to a single thread of execution."
>
>in at least a couple of places. Since you're not using multiple threads,
>there's absolutely no connection between the problem Richard Morris saw
>and the problem you're seeing.
On first blush, I assumed so. I have had two apps with this problem. The
first that had the problem was heavily threaded and ODBC has matching
warnings about threading. (Yes, I've found a way to share the database
objects between threads.) In retrospect, I'm still a little confused and
continue to suspect a relationship, but I'll take your word for it.
>>The line of code
>>in MFC responsible for causing messages [1], [2] and [3] above is in
>>DBCORE.CPP in CDatabase::Close() and reads:
>>
>> AFX_SQL_SYNC(::SQLDisconnect(m_hdbc));
>
>The underlying driver might be using threads, itself, to get the job done.
>I don't think ODBC itself ever spawns extra threads, but it might do so,
>too. But I don't think your conclusion that MFC is taking away something
>a closing thread in ODBC needs has any merit.
Hmm... just watch the debug window for the creation and exit of the threads
when you open and close the database objects. I thought it was kinda hard
to miss.
>I'm not convinced you've found a bug in MFC simply because I really don't
>understand what you're doing with the class. If you've not carefully
>worked out the lifecycle of your global object, you can get into very bad
>trouble. That's not a bug: it's a fact of life for any C++ class.
It's a bug somewhere. If MFC is following the rules, and if the rules are
wrong, then arguably there is nothing wrong with MFC. The carpet is being
yanked out from under the code somewhere, though. I'm grateful to MarkG
for pointing out the KB article. It's the final solution, but read on.
>If you want your object to be global, you can skip learning about the
>scope and lifetime of global objects by adding the CDatabase object to
>your CWinApp's instance data and accessing it via AfxGetApp(). This is
>really the safest way to go, since you know that the CDatabase object is
>going to construct only when MFC's initialized and destroy when it knows
>that everything is safe.
Point taken about using it as an object in the application's instance.
However, I need to point out that I was getting the crash before arriving
at the object's destructor. That was the case both when the object was
new'ed and when it constructed as a global object.
-----
Richard Morris wrote:
>I found a workaround in my code. The bug seems to have to do with
>the initialization and cleanup sequence of OLE, DAO, and thread management.
> [details removed]
I ultimately got the bug to go away by taking a similar approach of
re-ordering creation of objects. Effectively, we did what the LoadLibrary
solution of the KB article did: kept a portion of code in memory that would
otherwise have gone away.
In my case, I moved the OpenEx call from my main windows OnCreate to my
application's InitInstance. The matching CDatabase::Close call got moved
to my application's destructor. The problem went away.
Geez... was that problem beat on thoroughly enough? 8-) Many thanks to
all for all the good feedback.
| Tim Robinson | Once you let go of your liberty, you |
| http://www.ionet.net/~timtroyr | won't easily get it back. -- Plautus |
-----From: "Andreas Epple"
I have had the same problem. If you use the MS - ODBC drivers, try the
following:
//
// Bugfix for Jet - ODBC
//
VERIFY(LoadLibrary("MSJT3032.DLL"));
I found this hint in the MS knowledge database. You must not unload the
dll, WIN95 or WIN NT is doing this for you.
Bye
Andreas Epple
> >----------
> >From: Tim Robinson[SMTP:timtroyr@ionet.net]
> >Sent: Tuesday, March 11, 1997 2:58 AM
> >To: mfc-l@netcom.com
> >Subject: CDatabase::Close() causing exception
> >
> >Environment: VC++ 4.2b, NT 4.0
> >The Primary Symptom:
> >
> >First-chance exception in MyApp.exe (NTDLL.DLL): 0xC0000005: Access
> >Violation.
> >
****************************************************************
Live now.
Make now always the most precious time.
Now will never come again.
- Captain Jean-Luc Picard, U.S.S. Enterprise
Mike Blaszczak -- mikeblas@nwlink.com
Wednesday, March 26, 1997
At 11:40 3/25/97 -0800, Richard Morris wrote:
>Here is a summary of some other responses and solutions people have found to
>the problem you are facing. It looks like it is an MFC bug,
No, it doesn't. The very notes you quote explain that it's actually a
bug in the database APIs, not in MFC.
In the meantime, Minh C. Tran's note doesn't mention _anything_ about using
_any_ database API, so it's really hard to understand how you've jumped from
someone who reports an access violation in a COM app they're writing to
there being a bug in MFC's database access classes.
Would you care to explain that logic?
.B ekiM
Crotch Rocket / Full-Body Rocket / Trip Report Central!
95 Honda VFR-750F / 94 Mazda RX-7 / http://www.nwlink.com/~mikeblas/
Less work, more hockey!
These words are my own - I do not speak on behalf of Microsoft.
Jean Libera -- jean.libera@tdata.com
Thursday, March 27, 1997
First, you must Release pUnk and pClf. I have found that if you don't
release these, your app will sometimes refuse to exit.
In addition, after you release them, you should set them to NULL. I once
had a similar problem with exceptions on exit from a program which used
OLE, and setting the pointers to NULL after I was finished solved the
problem. I speculate that the pointers were in the heap, and somehow tagged
as OLE pointers, so the runtime env. was trying to automatically delete
them as part of the exit process.
Jean Libera
jlibera@tdata.com
>I am writing an OLE-COM client application and everytime I exit or close my
>application I get the following access violation:
>Unhandled exception in (NTDLL.DLL):0xC0000005:Access Violation
>Here is the cut down version of my application:
>hr = ::CLSIDFromProgID(...);
>hr = ::CoGetClassObject(...);
>pClf->CreateInstance(...);
>pUnk->QueryInterface(...);
Become an MFC-L member
| Вернуться в корень Архива
|