12,244,322 members (57,342 online)
Forgot your password?
Sign in using
Chapters and Sections
Article Help Forum
Submit an article or tip
Post your Blog
Ask a Question
View Unanswered Questions
View All Questions...
All Message Boards...
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Design and Architecture
C / C++ / MFC
ATL / WTL / STL
Objective-C and Swift
Hardware & Devices
Hosting and Servers
Silverlight / WPF
Site Bugs / Suggestions
Spam and Abuse Watch
The Insider Newsletter
The Daily Build Newsletter
Most Valuable Professionals
The Insider News
The Weird & The Wonderful
General Indian Topics
General Chinese Topics
What is 'CodeProject'?
Ask a Question
Bugs and Suggestions
Article Help Forum
Advertise with us
Comments by Michael Bergman (Top 6 by date)
You are, of course, right about Release(). I knew that but I must have conflated that with another call that I made to access the object.
I don't think I can be more specific as this was five years ago, I but I think I can describe the problem a little more thoroughly.
There are three components:
1. An ActiveX control hosted in an application.
2. An Out-of-Proc COM Server which does work for the ActiveX control. The COM Server instantiates when call upon by the ActiveX control and closes when the ActiveX control closes with its host application.
3. Another Out-of-Proc COM Server which does work for the first COM Server. It is instantiated when the first COM Server calls it and it closes when it is released.
The problem is that the second COM Server crashes. We couldn't fix it because it was using propriatary API that we needed and that API was extremely buggy. Needless to say, it was a Microsoft API so we couldn't get them to fix it.
So what happens is:
ActiveX calls Server 1, gets a reference to Server 1
Server 1 call Server 2, Server 2 gets a reference to Server 1
Server 2 crashes,
Server 1 re-instantiates Server 2
Server 1 call Server 2 and get what it needs, Server 2 gets a reference to Server 1
Server 1 closes Server 2, Server 2 releases its reference to Server 1.
ActiveX host closes ActiveX control and releases its reference to Server 1
Server 1 does not close
Server 1 does not close because it still thinks the Server 2 which crashed still has a reference to it.
We were able to work around this problem, but it was a kludge. I was just wondering if anyone else had this particular problem (which I should have written more clearly the first time) and if they were able to resolve it.
Thanks for responding
Because I did not find it.
Why did you vote my question down?
Yes, I've looked at it briefly. I may have to go back and slog through the standard document, but, being the lazy person that I am, I was hoping there was a simpler way to get to the information I want. Thanks.
SymFromName, like SymGetModuleInfo64, expects you to provide an structure for it to fill out so you are not really getting any addresses from dbghelp, you are providing an address to dbghelp so it can give you information for you to use as you want.
Ouch! I just saw what you did wrong. In your code you declare:
This is an uninitialized pointer. You should have declared:
mod_Image.SizeOfStruct = sizeof(IMAGEHLP_MODULE64);
BOOL retVal = SymGetModuleInfo64(g_hProcess,dwBaseAddr, &mod_Image);
at that point mod_Image should be filled out and you own it.
Can you be more specific about what you want to do?
Web01 | 2.8.160426.1 | Last Updated 1 Jan 1900
All Rights Reserved.
Terms of Service